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ABSTRACT 

The dynamic nature of Web data gives rise to a multitude of prob¬ 
lems related to the identification, computation and management of 
the evolving versions and the related changes. In this paper, we 
consider the problem of change recognition in RDF datasets, i.e., 
the problem of identifying, and when possible give semantics to, 
the changes that led from one version of an RDF dataset to an¬ 
other. Despite our RDF focus, our approach is sufficiently general 
to engulf different data models that can be encoded in RDF, such 
as relational or multi-dimensional. In fact, we propose a flexible, 
extendible and data-model-independent methodology of defining 
changes that can capture the peculiarities and needs of different 
data models and applications, while being formally robust due to 
the satisfaction of the properties of completeness and unambiguity. 
Further, we propose an ontology of changes for storing the detected 
changes that allows automated processing and analysis of changes, 
cross-snapshot queries (spanning across different versions), as well 
as queries involving both changes and data. To detect changes and 
populate said ontology, we propose a customizable detection algo¬ 
rithm, which is applicable to different data models and applications 
requiring the detection of custom, user-defined changes. Finally, 
we provide a proof-of-concept application and evaluation of our 
framework for different data models. 

1. INTRODUCTION 

With the growing complexity of the WWW, we face a com¬ 
pletely different way for creating, disseminating and consuming 
big volumes of information. Large-scale corporate, government, 
or even user-generated data are published and become available 
to a wide spectrum of users. DBpedia, Freebase, YAGO and At¬ 
las are, among many others, examples of large data repositories, 
which store information about various entities, including their re¬ 
lationships. Typically, data in such datasets are represented using 
the RDF model GD , in which information is stored in triples of the 
form (subject, predicate, object), meaning that subject is related to 
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object via predicate. 

Dynamicity is an indispensable part of the current web; datasets 
are constantly evolving for several reasons, such as the inclusion 
of new experimental evidence or observations, or the correction 
of erroneous conceptualizations GD As an example, consider 
the detected number of changes between the versions 12.07 and 
13.05, and 13.05 and 13.07 of Atlas, which are 879.5M and 801.2M 
triples, respectively, while between the versions 3.7 and 3.8, and 
3.8 and 3.9 of the English DBpedia are 20.7M and 9.3M triples 
(Figure]^. 

This constant evolution poses several research problems, which 
are related to the identification, computation, storage and manage¬ 
ment of the evolving versions. An important question is how to 
support complex changes, whose constituent changes are seem¬ 
ingly unrelated and may occur on disparate pieces of data, but 
together as a whole they have a semantically coherent meaning 
for an application domain. Clearly, understanding and detecting 
the changes of evolving datasets is a prerequisite to address these 
problems. In particular, finding the differences (deltas) between 
datasets has been proved to play a crucial role in various cura- 
tion tasks, such as the synchronization of autonomously developed 
datasets versions j^, or the visualization of the evolution history of 
a dataset QD Deltas are also necessary in certain applications that 
require access to previous versions of a dataset to support histori¬ 
cal or cross-snapshot queries (e.g., (19|), in order, for example, to 
identify past states of the dataset, understand the evolution process, 
or detect the source of errors in the current modelling. 

In general, there are two ways to record the occurring changes. 
The first is by constantly monitoring the dataset and logging any 
change, which requires a closed and controlled system, where all 
changes pass through a dedicated application that records every 
change as it happens. A more flexible method includes detecting 
a posteriori the changes that happened. This avoids the need to 
have a controlled system, and allows remote users of a dataset to 
identify changes, even if they have no access to the actual change 
process or knowledge that it happened. Here, we focus on the latter 
case, which is more challenging and interesting, even though most 
of the proposed solutions (namely, the definition of a language of 
changes and the representation of the changes) are applicable in 
both scenarios. 

Recognition of changes is based on 3 main pillars, namely defin¬ 
ing, representing and detecting changes. The first pillar (defining 
changes) is related to the definition of a language of changes, which 
is based on the set of changes that are understandable by the system. 
Defining the language of changes includes identifying the types of 
changes that will be detected, their formal definition (e.g., their se- 


mantics and parameters), and takes into account the need for com¬ 
plex, domain-specific changes. It has been argued that the language 
of changes as a whole, should be well-behaved in the sense of satis¬ 
fying certain properties, namely being complete and unambiguous, 
so as to allow the generation of unique deltas in a deterministic 
manner (E) The definition of changes is given in Section]^ 

The second pillar (representing changes) is related to the rep¬ 
resentation scheme used for storing the detected changes. This is 
necessary to allow a persistent representation and storage of the 
detected changes, as well as to support navigation among versions, 
analysis of the deltas, cross-snapshot or historic queries, and the 
raising of changes as first class citizens in a multi-version repos¬ 
itory. Our approach is based on the definition of an ontology of 
changes that satisfies these goals. The representation scheme of 
the proposed changes is given in Section|^ 

The third pillar (detecting changes) is related to the algorith¬ 
mic definition of the detection process. This process identifies 
the changes applied between any two versions, based on the ac¬ 
tual change definitions in the language of changes, and stores the 
results in the ontology of changes. Our approach for change de¬ 
tection is based on the execution of appropriately defined SPARQL 
queries, whose answers determine the detected changes. Details on 
the detection process are given in Section]^ 

A major challenge related to change detection and deltas is that 
no language of changes is suitable for all different applications and 
data models. There are two reasons for that. First, the different 
types of data available on the Web are often represented using dif¬ 
ferent models, which call for different changes. Second, different 
uses (or users) of the data may require a different set of changes 
being reported, or the definition of special types of changes that 
happen often or are important for the operation of the data-driven 
application. Therefore, there is no one-size-fits-all solution for the 
problem of change recognition. 

In this work, we propose a flexible framework for change recog¬ 
nition that can be applied to different data models and applica¬ 
tions. Our intention is not to provide a single solution, but a generic 
methodology for defining the three components of a multi-version 
repository, through which different solutions, suitable for different 
needs, can be developed. Even though our framework is designed 
for RDF, our approach is applicable to any data model representable 
in RDF, i.e., RDF is used as a unifying underlying model to achieve 
this generality. 

In overall, our contributions are as follows: 

• Regarding the definition of changes, the objective of gen¬ 
erality is met by providing two different types of changes, 
namely simple and complex (see Section]^. The former type 
is meant to capture fine-grained changes for the data model 
at hand, and should meet the requirements of completeness 
and unambiguity. The latter type is meant to capture more 
coarse-grained, or specialized, changes that are useful for the 
application at hand; this allows a customized behaviour of 
the change detection process, depending on the actual needs 
of the application. Complex changes are totally dynamic, 
and can be defined even at run-time, greatly enhancing the 
flexibility of our approach. 

• For the purposes of representation, the proposed ontology of 
changes is designed to be generic enough, so as to be cus¬ 
tomizable for different languages of changes. This allows 
us to meet the aforementioned generality goal, as detailed in 
Section|4] 

• The detection process is defined in a customizable manner, as 
the core detection algorithm is agnostic to the set of simple 


or complex changes used. The customization for the actual 
language of changes employed is based on the definition of 
appropriate SPARQL queries (one per change) that come as 
parameters to the algorithm, thereby allowing new changes 
to be easily defined. Details are given in Section]^ 

• An additional contribution is the application of this work 
for data models other than the pure RDF model, namely the 
multi-dimensional model that has been transformed to the 
RDF Data Cube vocabulary, while it could be also applied 
similarly to the relational model. This application is meant 
as a proof-of-concept that the proposed approach is indeed 
capable of supporting diverse needs, and is not exhaustive in 
terms of the types of applications or models that our frame¬ 
work supports. 

• Finally, we provide experiments showing that the most cru¬ 
cial parameter in the change recognition process is the total 
number of detected changes rather than the size of the ex¬ 
amined datasets. We prove also that the number of simple 
changes is proportional to the number of triples which will 
be inserted into the ontology. Except from the evaluation 
aspect of our framework, our experiments offer a detailed 
look on the evolution of real-world, big datasets, as we record 
changes and provide an analysis of their form. 

The approach proposed in this paper extends our previous work 
on change detection (E)^ by providing a more generic change def¬ 
inition framework; here, we experience significantly improved per¬ 
formance (about 1 order of magnitude), scalability, as well as in¬ 
creased generality and applicability. 

2. PRELIMINARIES 

We consider two disjoint sets U, L, denoting the URIs and lit¬ 
erals (we ignore here blank nodes that can be avoided when data 
are published according to the Linked Data paradigm). An RDF 
triple (E) is a tuple of the form (subject, predicate, object) and 
asserts the fact that subject is associated with object through predi¬ 
cate. The set T= U x U x (U U L) is the set of all RDE triples. An 
RDF dataset D consists of a set of RDF triples. In the following, 
we denote by Doid, Dnew the old and new versions, respectively, 
of a dataset D. 

SPARQL 1.1 | |17| is the official W3C recommendation language 
for querying RDF graphs. The building block of a SPARQL state¬ 
ment is a triple pattern tp that is like an RDF triple, but may have 
a variable (prefixed with character ?) in any of its subject, predi¬ 
cate, or object positions; variables are taken from an infinite set of 
variables V, disjoint from the sets U, L, so the set of triple patterns 
is: TP= (U U V) X (U U V) x (U U L U V). SPARQL triple pat¬ 
terns can be combined into graph patterns gp, using operators like 
join (“.”), optional (OPTIONAL) and union (UNION) Q] and may 
also include conditions (using FILTER). In this work, we are only 
interested in SELECT SPARQL queries, which are of the form: 
“SELECT WEERE gp”, where n > 0, G V 

and gp is a graph pattern. 

Eor the evaluation of SPARQL queries, we follow the semantics 
discussed in (EllI)- Evaluation is based on mappings, which are 
partial functions /r : V i—^ U U L that associate variables with URIs 
or literals (abusing notation, p{tp) is used to denote the result of 
replacing the variables in tp with their assigned values according 
to p). Then, the evaluation of a SPARQL triple pattern tp on a 
dataset D returns a set of mappings (denoted by [[fp]]®) such that 
p{tp) G D for p € [[fp]]®. This idea is extended to graph pat¬ 
terns by considering the semantics of the various operators (e.g.. 


[[tpi UNION tp 2 ]f = [ltpi]f U [[tp 2 ]]®). Given a SPARQL 
query “SELECT vi,... ,v„ WHERE gp”, its result when ap¬ 
plied on D is {p{vi),..., p{vn)) for p £ [[gp]]®. For the precise 
semantics and further details on the evaluation of SPARQL queries, 
the reader is referred to QUg. 

3. DEFINING CHANGES 

Our purpose in this work is to provide a change recognition 
method, which, given two (subsequent) dataset versions Doid, Dn^w, 
would produce their delta (A), i.e., a formal description of the 
changes that were made to get from Dou to A delta is 

based on a language of changes {£), i.e., a set of formal definitions 
of the changes that the delta could contain and, subsequently, the 
change detection method understands and detects; these changes 
should correspond to the evolution primitives of the data model un¬ 
der consideration. 

A language of changes, in its simplest form, consists of additions 
and deletions of elements (i.e., triples for the RDF case) from a 
dataset, i.e., changes of the form Addif) / Del{t). Such a delta is 
called a low-level delta [22] and can be easily computed as follows: 
MDold, = {A^t) I t £ D„ew \ Dold} u {Del{t) \ t £ 

Dold \ Dnew} • 

Low-level languages (and deltas) are easy to define and detect, 
and have several nice properties (22| ; however, the representation 
of changes at the level of (added/deleted) triples, leads to a syn¬ 
tactic delta, which does not capture the semantics of a change and 
generates results that are not intuitive enough for the human user. 
For example, in the RDF context, the plain deletion of an individual 
(class instance) would correspond to a multitude of triple deletions 
(namely, all the triples that contain this URI, such as property in¬ 
stances); listing all these changes does not immediately convey the 
message that an individual was deleted, and the human observer 
may find it hard to decipher the intent of the actual changes that 
took place (E) This problem is even more serious for other data 
models (e.g., multi-dimensional) that are translated into RDF; in 
this case, the low-level deltas, which are described in RDF jargon, 
need to be “translated back” into the original data model, making 
deciphering even more difficult. 

To address this problem, high-level deltas have been proposed p4) , 
which aim to describe changes at a more intuitive level, in order 
to make them more human-understandable. In the above exam¬ 
ple, the output would be a “delete individual” change, that imme¬ 
diately conveys the message that all triples that include a given 
URI (individual) were deleted. The main idea behind achieving 
this is to group low-level changes into high-level ones, under some 
conditions. For the purposes of this paper, we organize high-level 
changes in two major types, namely simple and complex, each of 
which represents changes with a certain granularity and role in the 
model. Details on these two types are given below. 

3.1 Simple Changes 

In general, the role of simple changes is to describe changes (evo¬ 
lution primitives) specific to the data model at hand; e.g., for the 
multi-dimensional model, we would expect changes like “Add_Di- 
mension” or “Attach_Type_To_Measure”. Using simple changes, 
the user can abstract from the syntactical and representational pecu¬ 
liarities of the underlying data model (including its possible trans¬ 
lation to RDF format), thereby making deltas more intuitive. 

A simple change (e.g., Attach_Type_To_Measure(m,t)), is com¬ 
posed of the change name (i.e., Attach_Type_To_Measure) and the 
change parameters (i.e., (m,t)). Its main characteristic is the triples 
that would be added/deleted from the RDF representation of the 
dataset when such a change occurs. These correspond to the triples 


that are directly associated with said change and are assumed to 
be captured by the simple change. For example, the above change 
would be associated with the triple (m, rdfs : range, t) (which in¬ 
dicates that t is the type of measure m); if said triple is found in 
Dnsw, but not in Doid, then this indicates that a new type (t) has 
been attached to measure m (thus, Attach_Type_To_Measure(m,t) 
should be detected). 

Triples of this type are required to be in one version but not in 
the other (i.e., in low-level delta) and are directly associated (con¬ 
sumed) by the corresponding simple change. Consumption in this 
respect means that the corresponding low-level change is captured 
(described) by said simple change. 

A simple change can also have a number of logical conditions 
required for detection. For example, the triple (m, rdfs : range, t) 
may also indicate that a datatype (t) is attached to a dimension m. 
To determine whether the inclusion of such a triple in corre¬ 

sponds to an Attach_Type_To_Measure(m,t) change (as opposed to 
an Attach_Datatype_To_Dimension(m,t) change), we need a con¬ 
dition that will determine whether m is a measure or a dimension. 
In this case, the Attach_Type_To_Measure(m,t) would require the 
presence of the triple (m, rdf ; type, qb : measureProperty) in 
Dne-w- Note that, in general, conditions may refer to both the old 
and the new version. Unlike consumed triples, the triples appear¬ 
ing in conditions are not necessary added or deleted triples; their 
presence is necessary in either (or both) of the versions and their 
role is to disambiguate between similar changes. 

More formally, a simple change is defined as follows: 

Definition 1. A simple change c(pi ,... ,p„) is defined as a 
tuple of the form (5^, d~, fold, finew) where: 

• c is the name and pi,... ,Pn £ Y, n > 0, are the parameters 
of the change, 

• 5^ ,S~ C- TP are called the consumed added and consumed 
deleted triples, respectively, and are sets of triple patterns, 

• fioid, finew are graph patterns, called the conditions related 
to Bold, Dnew, respectively. 

In our running example, Attach_Type_To_Measure(m,t) has two 
parameters (m, t) and 5^ — {{m, rdfs : range, f)}, 5~ — 0, fioid = 
“ ”, <j>new = “(m, rdf : type, qb : measureProperty)". 

The structure of Definition [T] is used for defining the changes 
that the language of changes accepts, but any actual detection will 
give specific values (URIs or literals) to the parameters m, t of the 
change (e.g., Attach_Type_To_Measure(dm-measure:meas7v8t,dm- 
type:int)). This is captured with the following notion: 

Definition 2. Consider a change c{pi,... ,p„). Then, an 
assignment xi,..., Xn of URIs/literals to variables pi,... ,pn is 
called an instantiation of c and denoted by c{xi,..., Xn). 

Now we are in position to formally define the detectability of 
a change instantiation. Intuitively, a change instantiation corre¬ 
sponds to a certain assignment of (some of) the variables in J"*", 
S~, fioid, fine-w', the assignment should be such that the conditions 
(fioid, fino-w) are true in the underlying datasets, and the triples that 
correspond to the triple patterns in 5”'', S~ are found in the low- 
level delta. More precisely: 

Definition 3. A change instantiation c(a:i,..., Xn) of a sim¬ 
ple change c(pi,... ,pn) is detectable for the pair Doid, Dnew 
iff there is a p £ [[(j)o;d]]^°‘‘^ H [[0neti,]]®"'™ such that for all 
tp £ 5+.- p(tp) £ Dnew \ Doid and for all tp £ 5~: p{tp) £ 
Doid \ Dnew and for all i: p{pi) = Xi. 
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Figure 1: Visualization of Completeness and Unambigulty 

Then, a detectable change consumes the triples that correspond 
to the triple patterns in 5^, <5“. Formally: 

Definition 4. A detectable change instantiation c{xi,,Xn) 
of a simple change c(pi,... ,Pn) consumes t £ Dne-w \ Doid (re¬ 
spectively, t G Doid \ Dne-w) iff there is a p G [[(t>oid]]^°‘‘‘ n 
and a tp £ 5'^ (respectively, tp G 3~) such that 
p{tp) = t and for all i: p(pi) = Xi. 

The concept of consumption represents the fact that low-level 
changes are “assigned” to simple ones, essentially allowing a group¬ 
ing (partitioning) of low-level changes into simple ones. To fulfil 
its purpose, this “partitioning” should be perfect, in the sense that 
all low-level changes should be associated to one, and only one, 
simple change. This is captured by the properties of completeness 
and unambiguity. Formally: 

Definition 5. Consider a set of simple changes C. This set 
is called complete iff for any pair of versions Doid, Dnew and for 
all t G (Dnew \ Doid) U (Doid \ Dnew), there is an instantiation 
c(xi ,... ,Xn) of some c £ C such that c(a;i ,..., x„) is detectable 
and consumes t. 

Definition 6. Consider a set of simple changes C. This set 
is called unambiguous iff for any pair of versions Doid, Dnew and 
for all t £ (Dnew \ Doid) U (Doid \ Dnew), (f 0 , c £ C and 
c(xi,... ,Xn), c' (x'l, ..., x'm) are detectable and consume t, then 
c(xi,. ..,Xn)= c'(®i, . . .,x'm)- 

In a nutshell, completeness guarantees that all low level changes 
are associated with at least one simple change, thereby making the 
reported delta complete (i.e., not missing any change); unambigu¬ 
ity guarantees that no race conditions will emerge between sim¬ 
ple changes attempting to consume the same low level change (see 
Figure[T]for a visualization of the notions of completeness and un¬ 
ambiguity). The combination of these two properties guarantees 
that the delta is produced in a deterministic manner and that it will 
properly reflect the changes that were actually performed. 

3.2 Complex Changes 

To guarantee completeness and unambiguity, simple changes must 
be defined at design time, and remain immutable between differ¬ 
ent applications; for changes corresponding to custom, application- 
specific evolution primitives, we use complex changes. Complex 


changes can also be used to define changes that were not foreseen 
at design-time. This would give an extra flexibility to the user to 
describe more specialized, coarse-grained changes, which are rele¬ 
vant to a certain application, but not generic enough to be consid¬ 
ered part of the “core” language of (simple) changes. This essen¬ 
tially allows extending the language of changes at run-time. 

Complex changes are defined in a way similar to simple ones; 
there are certain differences though. First, complex changes are 
not directly associated with low level changes; instead of 5^, 5~, 
they include a set of simple changes, denoted by 5“, which corre¬ 
sponds to the set of simple changes that should be detectable in 
order for said complex change to be detectable. This is neces¬ 
sary to make their definition more user-friendly, given that com¬ 
plex changes will be defined by the end-user who does not un¬ 
derstand low level changes. Second, as complex changes can be 
freely defined by the user, it would be unrealistic to assume that 
they will have any quality guarantees, such as completeness or un¬ 
ambiguity. As a consequence, the detection process may lead to 
non-deterministic consumption of simple changes and conflicts; to 
avoid this, complex changes are associated with a priority level, 
which is used to resolve such conflicts. 

Furthermore, complex changes support associations, i.e., cor¬ 
respondences between URIs/literals that are necessary to support 
changes like renames and merge/splits (T4). In general, an asso¬ 
ciation a is a pair (X, Y) where X, Y are sets of URIs, literals 
or variables (called URIAiteral/variable association, respectively). 
Associations can have one of the following forms (where Vi may 
be a URI, literal or variable): 

• {ui} {^ 2 }, vi 7 ^ V 2 (rename) 

• {no} {m, ..., v„}, Vi 7 ^ Vj for i 7 ^ j (split) 

• {m, ..., v„} {no}, Vi 7 ^ Vj for i 7 ^ j (merge) 

A set of URI and literal associations should be provided as an 
input to the detection process. Such associations could be provided 
manually by the user, or automatically identified using, e.g., entity 
matching software | 20 | ; detecting associations is out of the scope of 
this paper. Given a mapping p and a variable association a, we will 
denote by p(a) the URFliteral association resulting from replacing 
all variables in a with their corresponding URI/literal according to 

p. 

Complex changes are useful in several applications. For exam¬ 
ple, various ontological applications refrain from deleting classes, 
but use a special subsumption relationship to a class “Obsolete” 
to indicate that a certain class (say, cl) should no longer be used. 
This action could be captured by the change Mark_as_Obsolete(cl), 
which would consume the simple change Add_SuperClass(cl, obs), 
where obs = geneontology : ObsoleteClass. 

The formal concepts associated with complex changes are simi¬ 
lar to the ones related to simple changes: 

Definition 7. A complex change c(pi,... ,Pn) is defined as 
a tuple of the form (3“, fold, 4>new,A, P) where: 

• c is the name and pi,... ,Pn £ Y, n > 0, are the parameters 
of the change, 

• 5“ is a set of simple changes called the related simple changes, 

• fold, fnew are graph patterns, called the conditions related 
to Doid, Dnew, respectively, 

• A is a set of variable associations. 











• P is a number corresponding to the priority level of the com¬ 
plex change. 

In our running example, Mark_as_Obsolete(cl) has one param¬ 
eter (cl) and 5“ = {Add_SuperClass{cl, obs)}, fold = “obs = 
geneontology:ObsoleteClass”, fnew = “ .4 = 0, P = 2. 

The definition of complex change instantiations is identical to 
Definition|^ For detectability, we have a series of definitions, so as 
to take into account priorities: 

Definition 8 . A change instantiation c(a;i,..., Xn) of a com¬ 
plex change c{pi,... ,p„) is initially detectable for the pair Doid, 
Driew and the associations iffthere is a p € 

such that for all c'(p{pi),..., p{pn)) G 5“’, c'{p{pi), 
.. ., p{p„)) is detectable, for all a £ A, p{<x) G ^OaidPncu, 
for all i, p{pi) = Xi. 

Definition 9. An initially detectable change instantiation c{xi, 
.. . ,Xn) of a complex change c(pi ,... ,p„) consumes a simple 
change instantiation c' {x'l ,..., of a simple change c' {p'l,..., 

p'm) iff c'ip'i,.. .,p'm) G and there is a p G PI 

such thatfor all oi G A, p{a) G A and 

for all i, p{pi) = Xi, p{pi) = xf 

Definition 10. A change instantiation c{xi,... ,Xn) of a com¬ 
plex change c{pi,... ,Pn) is detectable for the pair Doid, Dnew 
and the associations ijfp p initially detectable for the 

pair Doid, D„ew and the associations there is no 

initially detectable change instantiation of another complex change 
with a higher priority that consumes the same simple change. 

4. REPRESENTING CHANGES 

4.1 Motivation for the Ontology of Changes 

We treat changes as first-class citizens in order to be able to per¬ 
form queries analysing the evolution of datasets. Further, we are in¬ 
terested in performing combined queries, in which both the datasets 
and the changes should be considered to get an answer. To achieve 
this, the representation of the changes that are detected on the data 
cannot be separated from the data itself. 

For example, consider the following query: “return all countries 
for which the unemployment rate of their capital city increased at 
a rate higher than the average increase of the country as a whole 
between versions Doid and Dnew”. This query requires access to 
the data (to identify countries and capitals) and to the changes (to 
describe the actual increase in the rates of unemployment for each 
city and country). Therefore, to answer it, the changes should be 
stored in a structured form and their representation should include 
connections with the actual entities (cities or capitals) that they re¬ 
fer to. Note that the definition of a cross-snapshot query language 
that treats changes as first-class citizens is outside the scope of this 
paper, however this work provides a formalism on which such a 
query language can be based. Therefore, we propose representing 
changes as special entities in an RDF dataset, with connections to 
the actual data, so that a detectable change can be associated with 
the corresponding data entities that it refers to. 

More specifically, we propose an ontology of changes for storing 
the detected changes, thereby allowing a supervisory look of the 
detected changes and their association with the entities they refer to 
in the actual datasets, facilitating the formulation and the answering 
of queries that refer to both the data and their evolution. 

In said ontology, the schema describes the definition of the changes 
(c(pi ,... ,Pn) - see Definitions [^1^, whereas information on de¬ 
tected changes (which are change instantiations - see Definition|^ 
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Figure 2: Representation of Simple Changes 


appear at the instance level, instantiating the corresponding classes. 
Specifically, at schema level, we introduce one class for each sim¬ 
ple and complex change c(pi,... ,p„) that is understood and con¬ 
sidered by the language of changes (£), and at instance level, we 
introduce one individual for each detectable change c{xi, 
in each pair of versions. 

4.2 Ontology of Changes: Schema Level 

For simple changes, the corresponding change definition is mod¬ 
elled as a subclass of the main class SimplejChange, and is as¬ 
sociated with adequate properties to represent its parameters (see 
Figure]^; each such property models the type of the parameter 
(e.g., whether it is a URI or a literal, via the classes rdfs:Resource, 
rdfs:Literal respectively) and its name (which is a descriptive name 
that allows a more intuitive interaction with the user, useful also 
during the construction of complex changes that consume said sim¬ 
ple change). Also a descriptive name (cname) is captured for each 
type of change. Note that conditions do not need to be stored. 

For complex changes, similar ideas are used; however, note that 
the information related to complex changes is generated on the fly 
at change creation time (in contrast to simple changes, which are in¬ 
built in the ontology at design time). In addition, more detailed in¬ 
formation related to the change should be available in the ontology 
for the change detection process, because, unlike simple changes, 
this information is not known at design time and cannot be embed¬ 
ded in the code. 

Each complex change is modelled as a subclass of the main class 
Complex_Change, and is associated with adequate properties to 
represent its parameters (see Figure]^. Again, parameters have a 
type and a name, which are modelled in the same manner as in sim¬ 
ple changes. In addition, each complex change is associated with 
the simple change(s) that it consumes, and includes also properties 
describing its (user-defined) descriptive name and its priority. 

Finally, for each complex change, the SPARQL query used for 
its detection, is automatically generated at change definition time; 
this is done for efficiency, to avoid having to generate this query in 
every run of the detection process. The SPARQL query encapsu¬ 
lates all the relevant information about the detection of the change, 
so further information on the complex change (namely conditions 
and associations) need not to be stored. 

4.3 Ontology of Changes: Data Level 

The instance level is used to store the detectable simple and com¬ 
plex changes. Each detectable change between any two versions 
is represented using a different individual associated through ade¬ 
quate properties with all relevant information, namely, the versions 
between which the change was detected and the exact values of its 












Figure 3: Representation of Complex Changes 
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parameters (of the change instantiation). For complex changes, we 
additionally need to include consumption information. Examples 
of such instantiations for simple and complex changes are shown in 
Figures|^and[^ for the detectable changes Attach_Type_To_Mea- 
sure(dm — measure : meas7v8t, dm — type : int) and 
Mark_as_Obsolete (e/o : £'F’0_0004151), respectively. 

4.4 Ontology of Changes: Associations 

Another useful feature of the ontology of changes is the storage 
of associations, which are necessary for the detection of complex 
changes. Associations are stored as instances classified under the 
class Association, and record the versions between which they are 
applicable, as well as the old and new values in the corresponding 


cname cname 




Figure 6: Representation of Associations 


association. For example, Figure|^shows the representation of the 
associations {xl} ^ {x2} and {t/1} {j/2, j/3}, which appear 

between versions vl,v2. 

5. DETECTING AND STORING CHANGES 

The change detection process is responsible for the detection of 
simple and complex changes between two dataset versions (and 
their corresponding associations, which are a necessary input for 
the detection of complex changes), as well as for the enrichment 
of the ontology of changes with information about the detectable 
changes. Thus, the process can be considered to comprise of two 
steps: the first is the identification of the detectable changes and the 
corresponding information (triples) to be inserted in the ontology of 
changes (triple creation), and the second is the actual ingestion of 
said information in the ontology of changes (triple ingestion). 

To detect simple and complex changes, we rely on plain SPARQL 
queries, which are generated from the information drawn from the 
definition of the corresponding changes (Definitions [T0l >. For 
simple changes, this information is known at design time, so the 
query is loaded from a configuration file, whereas for complex 
changes, the corresponding query is generated once at change-creation 
time (run-time) and is loaded from the ontology of changes (see 
Figure]^. The results of the generated queries determine the change 
instantiations that are detectable; this information is further pro¬ 
cessed to determine the actual triples to be inserted in the ontology 
of changes. Recall that this depends on the actual detected change 
and its type (see Section]^. 

More specifically, the SPARQL queries used for detecting a sim¬ 
ple change are SELECT queries, whose returned values are the 
parameter values of the change; thus, for each parameter of the 
change definition, we put one variable in the SELECT clause. Then, 
the WHERE clause of the query includes the triple patterns that 
should (or should not) be found in each of the versions in order 
for a change instantiation to be detectable; more specifically, the 
triple patterns in <5^ must be found in Dnew but not in Doid, the 
triple patterns in 5~ must be found in Doid but not in D„sui, and 
the graph patterns in (paid, <t>new should be applied in Doid, D„ow, 
respectively. 

Let’s use this methodology to construct the SPARQL query for 
the simple change Attach_Type_To_Measure(m,t) in which: = 

{(m, rdfs : range, f)}, <5“ = 0, (paid = cpnew = “(m, rdf : type, 
qb : measureProperty)’’. The corresponding SPARQL query is: 

SELECT ?ra ?t WHERE { 

GRAPH D„ew{ rdf:type qb:MeasureProperty. 

?m rdfs:range ?t. } 

FILTER NOT EXISTS 

{ GRAPH Doidi '?ni rdfs: range ?t. } } 

} 


Figure 5: Representation of Complex Change Detection 


























































Each result row of this query corresponds to the parameter values 
of one detectable change instantiation; for example, if the query re¬ 
turns the pair (dm-measure:meas7v8t,dm-type:int), then the change 
instantiation Attach_Type_To_Measure(dm-measure:meas7v8t,dm- 
typeunt) is detectable. 

The generation of the SPARQL queries for the complex changes 
follows a similar pattern. One difference is that the WHERE clause 
should also include the required associations, which are assumed to 
be already stored in the ontology of changes. A second important 
difference is that complex changes check the existence of simple 
changes (namely, those found in the <5^ part of the complex change 
definition) in the ontology of changes, rather than triples in the two 
versions (as is the case with simple changes detection); therefore, 
complex changes should be detected after the detection of simple 
changes and their storage in the ontology. Note also that the consid¬ 
ered simple changes should not have been marked as “consumed” 
by other detectable changes of a higher priority; thus, it is impor¬ 
tant for queries associated with complex changes to be executed in 
a particular order, as implied by their priority. 

Let’s illustrate the above methodology to construct the SPARQL 
query for the complex change Mark_as_Obsolete(cl). This change 
has one parameter (cl) and <5^ = {Add_SuperClass{cl, obs)}, 
4>oid = “obs = geneontology:ObsoleteClass”, (pnew = “ ”, -4 = 0, 
P — 2. The corresponding SPARQL query is: 

SELECT ?cl WHERE { 

GRAPH <changesOntology> { 

?asc a CO:Add_Superclass; 
co:asc_pl ?cl; 
co:asc_p2 ?obs. 

FILTER NOT EXISTS { ?cc CO:consumes ?asc } 
FILTER (?obs = "geneontology:ObsoleteClass"). 
} 

} 

As with simple changes, each query result corresponds to the 
parameter values of a detectable change instantiation; for exam¬ 
ple, if the query finds the simple change Add_Superclass(efo: 
EFO_00 04151, geneontology : ObsoleteClass I which is 
not consumed by any complex change, then it will return efo: 
EFO_0 0 04151, which implies that the change instantiation 
Mark_as_Obsolete(ef o : EFO_00041511 is detectable. 

Following detection, the information about the detectable (sim¬ 
ple or complex) change instantiations must be stored in the ontol¬ 
ogy of changes. To do so, we have to process each result row to 
create the corresponding triple blocks, as specified in Section 
This is done as a separate process that first stores the triple blocks 
in a file (on disk) and subsequently uploads them in Virtuoso using 
Virtuoso’ bulk loading process (triple ingestion). 

Note that the detection and storing of changes could be done in 
one step, if one used an adequately defined SPARQL update state¬ 
ment that identified the detectable change instantiations, created 
the corresponding triple blocks and inserted them in the ontology 
using a single statement. However, this approach turned out to be 
slower by 1-2 orders of magnitude, partly because it does not ex¬ 
ploit bulk updates based on multiple threads, and also because bulk 
loading is much faster than inserting triples using SPARQL updates 
in Virtuoso. 

The described process enjoys the characteristics put forward in 
the previous sections, namely: 

Expressiveness: The algorithm supports the entire semantics of 
SPARQL, thereby allowing a very expressive method to de¬ 
fine changes. 


Extensibility: The addition of a new change (simple or complex) 
requires just the addition of the corresponding SPARQL query, 
with no further modifications on the source code. 

Data Model Insensitivity: The process can be applied in any data 
model (e.g., multi-dimensional) which can be expressed in 
RDF (see Section ignoring its internal representation; all 
peculiarities of the underlying data model are incorporated 
in the corresponding SPARQL queries, thereby allowing the 
code to be versatile. 

Cross-Platform Character: The process requires very generic RDF 
data management operations (SPARQL support and RDF data 
import), so it can be implemented in any triple store. 

6. APPLICATION OF THE FRAMEWORK 

As mentioned above, our framework is flexible and generic enough 
to be applicable to any data model, which is transformable to the 
RDF format. Thus, to apply our framework to any given data 
model, one first has to determine how to transform said data model 
in RDF. The second step is the definition of the simple changes 
that would comprise the language of changes (£)\ note that said 
changes should be complete and unambiguous for optimal results. 
Defining the simple changes amounts to identifying the SPARQL 
query that is necessary for detection, as well as the representation 
of the simple changes in the schema of the changes ontology; the 
latter can be easily automated. 

Complex changes need not be defined at this point, as they are 
created at run-time; to facilitate the definition of complex changes 
one could create an adequate user-friendly interface, that could (po¬ 
tentially) sacrifice some of the expressive power of the complex 
change definition (Definition in favour of user-friendliness; at 
any rate, the definition of such an interface is beyond the scope of 
this work. 

Indicatively, we demonstrate, for visualization and experimenta¬ 
tion purposes, the above process for the RDF and multi-dimensional 
data models; a similar methodology could be used for other data 
models, e.g., relational, but further applications of our framework 
are omitted due to space limitations. 

6.1 RDF Model 

The RDF data model is a popular model for exposing, sharing, 
and connecting pieces of data, information, and knowledge on the 
Semantic Web. Scientists from various areas of expertise use RDF 
to publish their scientific observations and measurements on the 
Web. 

The case of RDF is straightforward in the sense that no data 
transformation is required. For the definition of simple changes, 
we used a set very similar to the so-called “basic changes” in OD- 
The full list of defined simple changes, along with details on their 
definition and the corresponding SPARQL queries used for detec¬ 
tion can be found in Appendix [B] 

6.2 Multi-dimensional Model 

The multi-dimensional data model is useful for capturing statis¬ 
tics and information on data items along several dimensions. The 
bridge to RDF is achieved through the Data Cube vocabular)[^which 
was proposed as a W3C recommendation to enable the publica¬ 
tion of statistical data flows and other multi-dimensional data sets 
over the Web. The Data Cube vocabulary allows multi-dimensional 
data to enjoy all the advantages of the LOD and RDF technolo¬ 
gies (knowledge sharing and interconnection) via its publication to 

'http://www.w3.org/TR/vocab-data-cube 



Table 1: Evaluated Datasets: Versions and Sizes 


Dataset 

Version 

# Triples 

RDF datasets 


V12.07 

457.951.940 

ATLAS 

V13.05 

422.144.126 


V13.07 

447.149.655 


v3.7 

48.898.490 

Dbpedia 

v3.8 

63.126.304 


v3.9 

67.980.265 


24-03-2009 

189.378 

GO 

22-09-2009 

195.125 


20-04-2010 

210.076 

Multi-dimensional datasets 


vl 

229.338.925 

41qc 

v2 

243.336.594 


v3 

243.449.874 


vl 

4.022.424 

Izph 

v2 

4.022.352 


v3 

4.022.208 


vl 

259.125 

lbu4 

v2 

270.049 


v3 

270.049 


RDF, thereby allowing publishers or third parties to annotate and 
link to specified data, which can he flexibly combined across dif¬ 
ferent datasets. 

To apply our framework to the multi-dimensional model, we 
adopt the transformation proposed by the Data Cube vocabulary. 
The definition of simple changes is based on the identification of 
all entities of the Data Cube vocabulary (i.e., fact tables, dimen¬ 
sions, observations, codelists, hierarchies, measures, attributes) in 
order to express special or generic cases of changes that appear in 
each of those entities. To achieve completeness and unambiguity 
in our definition of simple changes, we take into account how data 
cube entities are connected and which sets of triple patterns denote 
the existence/characteristics of the corresponding entities. Again, 
the full list of the defined simple changes for the multi-dimensional 
model, along with details on their definition and the corresponding 
SPARQL queries used for detection can be found in Appendix [C] 

7. EXPERIMENTAL EVALUATION 

Our framework was implemented and applied on the data mod¬ 
els described in Section]^ The evaluation considered some repre¬ 
sentative real-world datasets of various sizes from these two data 
models, and its aims were the following: 

• To identify the number and type of simple changes that usu¬ 
ally occur in real world settings. 

• To study the performance of our change detection process 
when dealing with real settings and quantify the effect of the 
size of the compared versions and the number of detected 
changes in the performance of the algorithm. 

To our knowledge, this is the first time that change detection has 
been evaluated for datasets of this size and versatility (RDF and 
multi-dimensional). 

7.1 Setting 

For the management of linked data (e.g., storage of datasets and 
query execution), we worked with a scalable triple store, namely 
the open source version of Virtuoso Universal Serve^ v7.10.3209 
(note that, our work is not bounded to any specific infrastructure or 

^http://virtuoso.openlinksw.com 


triple-store). Virtuoso is hosted on a machine which uses an Intel 
Xeon E5-2630 at 2.30GHz, with 384GB of RAM running Debian 
Linux wheeze version, with Linux kernel 3.16.4. The system uses 
7TB RAID-5 HDD configurations. From the total amount of mem¬ 
ory, we dedicated 64GB for Virtuoso and 5GB for the implemented 
application. Moreover, taking into account that CPU provides 12 
cores with 2 threads each, we decided to use a multi-threaded im¬ 
plementation; specifically, we noticed that the use of 8 threads dur¬ 
ing the creation of the RDF triples along with the ingestion process 
gave us optimal results for our setting. This was one more reason to 
select Virtuoso for our implementation, as it allows the concurrent 
use of multiple threads during ingestion. To eliminate the effects of 
hot/cold starts, cached OS information etc., each change detection 
process was executed 10 times and the average times were consid¬ 
ered. 

For our experimental evaluation, we used 3 RDF and 3 multi¬ 
dimensional datasets. The selected RDF datasets were atla:^ a 
subset of the English Dbpedi^(consisting of article categories, in¬ 
stance types, labels and mapping-based properties) and GCj^ The 
selected multi-dimensional datasets were provided by Datamarket 
and contain various statistics; in particular, 41q(|^ contains weather 
measurements from the Global Historical Climatology Network, 
lbul[^ contains numbers of employed persons between 15 and 64 
years old taking time off over the last 12 months for family sickness 
or emergencies and lzpl|^ contains information about unemploy¬ 
ment by sex, age, duration of unemployment and registration. All 
these measurements are taken from Eurostat. Tabled summarizes 
the corresponding versions and their sizes. 

7.2 Detected Changes 

The first part of our evaluation studies the number and type of 
simple changes that appear in the evaluated datasets. The results 
are summarized in Figure where we note the large number of 
changes which occurred during ATLAS evolution compared to the 
other datasets. This is explained by the fact that ATLAS contains 
experimental biological results and measurements that change over 
time, thus new versions are vastly different from previous ones. 
Moreover, note that the majority of changes (in all datasets except 
GO) are applied to the data level (e.g., Delete_Property_Instance), 
whereas in GO, we have also changes which are applied to the 
schema. 

On the multi-dimensional model, the majority of changes in all 
datasets are of type Add_Dimension_Value_to_Observation and De- 
lete_Dimension_Value_from_Observation. For both types of chan¬ 
ges, we observe that almost the same number of changes is re¬ 
ported, which implies that the datasets’ evolution mainly consists 
of changing dimension values upon observations; thus, creating a 
complex change to capture this pair of changes would immediately 
halve the number of reported changes. 

7.3 Performance of Change Detection 

The second part of our evaluation examines the performance of 
the detection process for the RDF and multi-dimensional testbeds; 
the results appear in Table 2. The reported performance is split into 
two parts, namely triple creation and triple ingestion; as explained 
in Section 1^ the former includes the execution of the SPARQL 

'http://WWW.ebi.ac.uk/gxa/home 

^http://dbpedia.org 

^http://geneontology.org 

^https://datamarket.com/data/set/41qc 

'https://datamarket.com/data/set/lbuh 

^https://datamarket.com/data/set/lzph 
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Figure 7: Detected Changes (RDF/Multi-dimensional) 
























































































































Table 2: Performance of Change Detection (RDF/Multi-dimensional) 


Datasets and Versions 

# Simple Changes 

# Ingested Triples 

Triple Creation (sec) 

Triple Ingestion (sec) 

Duration (sec) 

RDF datasets 

ATLAS: vl2.07-vl3.05 

879.512.096 

4.980.846.857 

7.294,73 

9.654,46 

16.949,20 

ATLAS: vl3.05-vl3.07 

801.278.339 

4.539.113.055 

5.953,07 

9.243,61 

15.196,68 

DBpedia: v3.7-v3.8 

20.752.280 

116.327.560 

465,26 

143,49 

608,74 

DBpedia: v3.8-v3.9 

9.343.769 

50.620.418 

296,20 

72,94 

369,14 

GO: 24-03-2009-20-04-2010 

11.949 

59.179 

0,80 

0,50 

1,31 

GO: 22-09-2009-20-04-2010 

25.299 

124.262 

0,96 

0,57 

1,52 

Multi-dimensional datasets 

41qc: vl-v2 

164.557.348 

978.012.302 

1.651,03 

994,85 

2.645,87 

41qc: v2-v3 

162.318.804 

973.837.296 

1.645,03 

996,96 

2.641,99 

Izph: vl-v2 

4.469.294 

26.815.814 

129,38 

46,91 

176,29 

Izph: v2-v3 

4.469.262 

26.815.494 

131,25 

47,33 

178,58 

lbu4: vl-v2 

475.666 

2.642.549 

7,42 

6,60 

14,02 

lbu4: v2-v3 

323.644 

1.941.848 

5,12 

5,97 

11,09 


queries for detection and the identification of the triples to be in¬ 
serted in the ontology of changes, whereas the latter is the actual 
enrichment of the ontology of changes. 

The main conclusion from Table 2 is that the number of simple 
changes is a more crucial factor for performance than the sizes of 
the compared versions (see also Table[TJ. This observation is more 
clear in the DBpedia dataset, where the evolution between v3.7 and 
v3.8 produces about twice the number of changes than the evolution 
between v3.8 and v3.9; despite the fact that in the second case, we 
have to compare larger dataset versions, the execution time in the 
former case is almost twice as large. Note that this conclusion holds 
for both triple creation and ingestion. 

More importantly, the performance of our approach is about 1 
order of magnitude faster than the performance reported by (1). 
upon which this work was built, even if the reported simple changes 
are compatible in both works, as the used simple changes for the 
RDF model are similar to the so-called “basic changes” in (E) 
For example, when comparing the performance of change detection 
over the GO versions v22-09-2009 and v20-04-2010, our approach 
needs 1,52 sec, while IE) requires 33,13 sec. 

8. RELATED WORK 

In general, approaches for change detection can be classified 
into low-level and high-level ones, based on the types of changes 
they support. Low-level change detection approaches report simple 
add/delete operations, which are not concise or intuitive enough 
to human users, while focusing on machine readability. Q dis¬ 
cusses a low-level detection approach for propositional Knowledge 
Bases (KBs), which can be easily extended to apply to KBs rep¬ 
resented under any classical knowledge representation formalism. 
This work presents a number of desirable formal properties for 
change detection languages, like delta uniqueness, reversibility of 
changes and the ability to move backwards and forwards in the his¬ 
tory of versions using the deltas. Similar properties appear in |22| , 
where a low-level change detection formalism for RDFS datasets 
is presented, as well as in (E) , upon which this work builds. 

describes a low-level change detection approach for the De¬ 
scription Logic £L\ there, the focus is on a concept-based de¬ 
scription of changes, and the returned delta is a set of concepts 
whose position in the class hierarchy changed. presents a for¬ 
mal low-level change detection approach for DL-Lite ontologies, 
which focuses on a semantical description of the changes. Re¬ 
cently, 0) introduced a scalable approach for reasoning-aware low- 
level change detection that uses a relational database management 
system, while m supports change detection between RDF datasets 


containing blank nodes. All these works result in non-concise, low- 
level deltas, which are difficult for a human to understand. 

High-level change detection approaches provide more human- 
readable deltas. Although there is no agreed-upon list of changes 
that are necessary for any given context, various high-level opera¬ 
tions, along with the intuition behind them, have been proposed 
[T31[T§. However, these approaches do not present formal seman¬ 
tics of such operations, or of the corresponding detection process; 
thus, no useful formal properties can be guaranteed. 

In (7l|I3|, a fixed-point algorithm for detecting changes, imple¬ 
mented in PromptDiff, is described. The algorithm incorporates 
heuristic-based matchers to detect changes between two versions, 
thus introducing uncertainty in the results, and obtaining a recall of 
96% and a precision of 93%. 

proposes the Change Definition Language (CDL) as a means 
to define high-level changes. A change is defined and detected us¬ 
ing temporal queries over a version log that contains recordings 
of the applied low-level changes. The version log must be updated 
whenever a change occurs; this overrules the use of this approach in 
non-curated or distributed environments. In our work, version logs 
are not necessary for the detection, as the delta can be produced a 
posteriori. Q focuses on defining a formal way to represent high- 
level changes as sequences of triples, but does not describe a detec¬ 
tion process or a specific language of changes. Finally, Q proposes 
an interesting high-level change detection algorithm that takes into 
account the semantics of OWL. 

9. CONCLUSIONS 

In this paper, we proposed an approach to cope with the dynam- 
icity of Web datasets via the management of changes between ver¬ 
sions. We advocated in favour of a flexible, extendible and triple¬ 
store independent approach, which is suitable for any data model 
that is representable in RDF terms. Our approach prescribes the 
definition of data model-specific, as well as application-specific, 
changes, and their management (definition, storage, detection) in a 
manner that ensures the satisfaction of formal properties (like com¬ 
pleteness and unambiguity), the flexibility and customization of the 
considered changes (via complex changes, which can be defined at 
run-time), as well as the easy configuration of a scalable detection 
mechanism (via a generic algorithm that builds on SPARQL queries 
that can be easily generated from the changes’ definitions). 

This work builds upon our previous work on the topic of change 
detection (El , by providing a more generic change definition frame¬ 
work, that is significantly more scalable and versatile than the one 
proposed in (E)’ as shown in Section]^ 
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APPENDIX 

A. CHANGE DETECTION ANALYSIS 


A.l Ontological Data Changes Analysis 

The following tables provide the change detection analysis for 
all the considered datasets. 


Table 3: DBpedia Dataset 



v3.7- 

v3.8 

v3.8- 

v3.9 

ADD_COMMENT 

0 

0 

ADD_DOMAIN 

0 

0 

ADD_LABEL 

229805 

49399 

ADD_PROPERTY_ 

INSTANCE 

11304462 

2693767 

ADD_RANGE 

0 

0 

ADD_SUPERCLASS 

0 

0 

ADD_SUPERPROPERTY 

0 

0 

ADD_TYPE_CLASS 

0 

0 

ADD_TYPE_TO_ 

INDIVIDUAL 

5904209 

4018781 

DELETE_COMMENT 

0 

0 

DELETE_DOMAIN 

0 

0 

DELETE_LABEL 

228628 

24330 

DELETE_PROPERTY_ 

INSTANCE 

1262564 

1207457 

DELETE_RANGE 

0 

0 

DELETE_SUPERCLASS 

0 

0 

DELETE_SUPERPROPERTY 

0 

0 

DELETE_TYPE_CLASS 

0 

0 

DELETE_TYPE_ 

EROMJNDIVIDUAL 

1822612 

1350035 


Table 4: GO Dataset 



go:24/3/2009- 

22-9-2009 

go:22-9-2009- 

20-04-2010 

ADD_COMMENT 

2632 

5350 

ADD_DOMAIN 

0 

0 

ADD_LABEL 

2335 

5588 

ADD_PROPERTY_ 

INSTANCE 

22 

36 

ADD_RANGE 

0 

0 

ADD_SUPERCLASS 

2966 

6624 

ADD_SUPERPROPERTY 

0 

0 

ADD_TYPE_CLASS 

0 

0 

ADD_TYPE_TO_ 

INDIVIDUAL 

893 

2527 

DELETE_COMMENT 

1707 

2303 

DELETE_DOMAIN 

0 

0 

DELETE_LABEL 

662 

1320 

DELETE_PROPERTY_ 

INSTANCE 

0 

0 

DELETE_RANGE 

0 

0 

DELETE_SUPERCLASS 

710 

1496 

DELETE_SUPERPROPERTY 

0 

0 

DELETE_TYPE_CLASS 

0 

0 

DELETE_TYPE_ 

EROMJNDIVIDUAL 

22 

55 


A.2 Multidimensional Data Changes Analysis 

The following tables provide the change detection analysis for 
all the considered datasets. 


Table 5: Atlas Dataset 



atlas: 12.07- 
13.05 

atlas: 13.05- 
13.07 

ADD_COMMENT 

707 

79 

ADD_DOMAIN 

42 

18 

ADD_LABEL 

45263390 

46060953 

ADD_PROPERTY_ 

INSTANCE 

282037024 

274667753 

ADD_RANGE 

48 

20 

ADD_SUPERCLASS 

18455 

5814 

ADD_SUPERPROPERTY 

239 

18 

ADD_TYPE_CLASS 

12574 

1813 

ADD_TYPE_TO_ 

INDIVIDUAL 

94519662 

92405466 

DELETE_COMMENT 

32 

79 

DELETE_DOMAIN 

0 

6 

DELETE_LABEL 

1017308 

43278600 

DELETE_PROPERTY_ 

INSTANCE 

353168759 

258055206 

DELETE_RANGE 

0 

6 

DELETE_SUPERCLASS 

1003 

1112 

DELETE_SUPERPROPERTY 

14 

16 

DELETE_TYPE_CLASS 

568 

135 

DELETE_TYPE_ 

EROMJNDIVIDUAL 

103472271 

86801245 



Table 6: lbu4 Datasets 



vl-v 2 

v2-v3 

ADD_CODELIST 

1 

0 

ADD_DIMENSION 

1 

0 

ADD_DIMENSION_VALUE_ 

161814 

161814 

TO_OBSERVATION 

ADD_GENERIC_DATATYPE 

1 

0 

ADDJNSTANCE 

6 

0 

ADD_LABEL 

2 

0 

ADD_OBSERVATION 

26969 

0 

ATTACH_CODELIST_TO_DIMENSION 

1 

0 

ATTACH_DATATYPE_TO_DIMENSION 

1 

0 

ATTACH_DIMENSION_TO_FT 

7 

7 

ATTACH_INSTANCE_TO_CODELIST 

6 

0 

ATTACH_MEASURE_TO_FT 

1 

1 

ATTACH_OBSERVATION_ 

TO_DATASET 

26969 

0 

ATTACH_OBSERVATION_TO_FT 

26969 

0 

DELETE_CODELIST 

1 

0 

DELETE_DIMENSION 

1 

0 

DELETE_DIMENSION_VALUE_ 

FROM_OBSERVATION 

155262 

161814 

DELETE_GENERIC_DATATYPE 

1 

0 

DELETEJNSTANCE 

5 

0 

DELETE_LABEL 

2 

0 

DELETE_OBSERVATION 

25877 

0 

DETACH_CODELIST_FROM_ 

1 

0 

DIMENSION 

DETACH_DATATYPE_FROM_ 

1 

0 

DIMENSION 

DETACH_DIMENSION_FROM_FT 

7 

7 

DETACH_INSTANCE_FROM_ 

CODELIST 

5 

0 

DETACH_MEASURE_FROM_FT 

1 

1 

DETACH_OBSERVATION_FROM_ 

DATASET 

25877 

0 

DETACH_OBSERVATION_ 

FROM_FT 

25877 

0 


Table 8: 4Iqc Dataset 



vl - v 2 

v2-v3 

ADD_DIMENSION_VALUE_ 

TO_OBSERVATION 

81112198 

81149958 

ADD_OBSERVATION 

2332944 

18880 

ATTACH_DIMENSION_TO_FT 

3 

3 

ATTACH_MEASURE_TO_FT 

1 

1 

ATTACH_OBSERVATION_ 

TO_DATASET 

2332945 

18880 

ATTACH_OBSERVATION_TO_FT 

2332945 

18880 

DELETE_DIMENSION_VALUE_ 

FROM_OBSERVATION 

76446308 

81112198 

DETACH_DIMENSION_FROM_FT 

3 

3 

DETACH_MEASURE_FROM_FT 

1 

1 


Table?: IzphDataset 



vl - v 2 

v2-v3 

ADD_DIMENSION_VALUE_ 

TO_OBSERVATION 

2234640 

2234640 

ADD_OBSERVATION 

148 

0 

ATTACH_DIMENSION_TO_FT 

6 

6 

ATTACH_MEASURE_TO_FT 

1 

1 

ATTACH_OBSERVATION_TO_ 

DATASET 

148 

0 

ATTACH_OBSERVATION_TO_FT 

148 

0 

DELETE_DIMENSION_VALUE_ 

FROM_OBSERVATION 

2234680 

2234640 

DELETE_OBSERVATION 

156 

0 

DETACH_DIMENSION_FROM_FT 

6 

6 

DETACH_MEASURE_FROM_FT 

1 

1 

DETACH_OBSERVATION_FROM_ 

DATASET 

156 

0 

DETACH_OBSERVATION_FROM_FT 

156 

0 



B. SIMPLE CHANGES FOR RDF DATA MODEL 

In this appendix, we list the simple changes referring to the RDF 
model. For each change and taking into account Definition we 
present: 

• Its name. 

• The intuition it captures, described in terms of the RDF model. 

• Its parameters, and the intuition behind each parameter. 

• The SPARQL query which will be used for its detection. 

• The consumed added and deleted triples <5^, <5“ C TP which 
are essentially sets of triple patterns. 

• The conditions related to Dou, which form the respec¬ 
tive graph patterns (l>oid, (pnew 

For simplicity, we will write vl to denote Dou^nd v2 to denote 
Driewin the following tables. Moreover, the conditions use clauses 
like “a does not appear in vl”, rather than the more verbose (and 
formal) graph pattern: < 7 )oid=“FILTER NOT EXISTS { a ?pl ?ol. 

?s2?p2 a. ?s3a?o3)". 


Change 

Add_Type_CUiss( a) 

Delete _Type_Class( a) 

Intuition 

Add object a ot type rdfs : class 

Delete object a ot type rdfs : class 

Parameters 

a = The added object 

a = ihe deleted object 

SPARQL used 
for detection 

SELECT ?a WHERE { 

GRAPH <v2> { 

?a rdf:type rdf:Class. } 

FILTER NOT EXISTS { 

GRAPH <vl> { 

?a rdf:type rdf:Class. } 

} } 

SELECT ?a WHERE { 

GRAPH <vl> { 

?a rdfrtype rdf:Class.} 

FILTER NOT EXISTS { 

GRAPH <v2> { 

?a rdfrtype rdf:Class.} 

} } 

( 5 + 

(a, rdf : type, rdfs : class) 

0 

s- 

0 

(a, rdf : type, rdfs : class) 

4>old 

a does not appear in vl 

- 

0new 

- 

a does not appear in v2 


Change 

Add_Type_Froperty( a) 

Delete _Type_Froperty( a) 

Intuition 

Add object a of type rdf : property 

Delete object a of type rdf : property 

Parameters 

a = The added object 

a = ihe deleted object 

SPARQL used 
for detection 

SELECT ?a WHERE { 

GRAPH <v2> { 

?a rdf:type rdf:Property . } 

FILTER NOT EXISTS { 

GRAPH <vl> { 

?a rdf:type rdf:Property . } 

} } 

SELECT ?a WHERE { 

GRAPH <vl> { 

?a rdf:type rdf:Property.} 
FILTER NOT EXISTS { 

GRAPH <v2> { 

?a rdf:type rdf:Property.} 

} } 


(a, rdf : type, rdf : property) 

0 

<5- 

0 

(a, rdf : type, rdf : property) 

4^old 

a does not appear in vl 

- 

^new 

- 

a does not appear in v2 


The changes Add_Type_Individual and Delete_Typeindividual are dehned analogously with the exception that 
(a, rdf : type, rdfs : resource) should be in 5^ (S~) instead of (a, rdf : type, rdf : property). 


Change 

Add_Superclass( a, b) 

Delete _Superclass( a, b) 

Intuition 

Parent b of class a is added 

Parent b of class a is deleted 

Parameters 

a = The class 
b = The new parent 

a = ihe class 
b = The old parent 

SPARQL used 
for detection 

SELECT ?a ?b WHERE { 

GRAPH <v2> { 

?a rdfs:subClassOf ?b } 

FILTER NOT EXISTS { 

GRAPH <vl> { 

?a rdfs:subClassOf ?b } 

} } 

SELECT ?a ?b WHERE { 

GRAPH <vl> { 

?a rdfs : subClassOf ?b } 

FILTER NOT EXISTS { 

GRAPH <v2> { 

?a rdfs : subClassOf ?b } 

} } 

(5+ 

(a, rdfs : subClassOf, b) 

0 

<5- 

0 

(a, rdfs : subClassOf, b) 


- 

- 

^new 

(a, rdf : type, rdfs : class). 

(b, rdf : type, rdfs : class) 

{a, rdf : type, rdfs : class). 

(6, rdf : type, rdfs : class) 


Change 

Add_Superproperty( Oyb) 

Delete _Superproperty( a, b) 

Intuition 

Parent b of property a is added 

Parent b of property a is deleted 

Parameters 

a = The property 

a = The property 


b = The new parent 

b = The old parent 

SPARQL used 
for detection 

SELECT ?a ?b WHERE { 

SELECT ?a ?b WHERE { 

GRAPH <v2> { 

GRAPH <vl> { 


?a rdfs:subPropertyOf ?b } 

?a rdfs:subPropertyOf ?b } 


FILTER NOT EXISTS { 

FILTER NOT EXISTS { 


GRAPH <vl> { 

GRAPH <v2> { 


?a rdfs : subPropertyOf ?b } 

} } 

?a rdfs : subPropertyOf ?b } 

} } 

5+ 

(o, rdfs : subPropertyOf, b) 

0 

s- 

0 

(a, rdfs : subPropertyOf, b) 

<t>old 

- 

- 

4^new 

(a, rdf : type, rdf : property). 

{a, rdf : type, rdf : property). 


(b, rdf : type, rdf : property) 

(6, rdf : type, rdf : property) 






Change 

Add_Type_To_lndividual( a, b) 

Delete _Type_From_Individual( a, b) 

Intuition 

'lype b ot individual a is added 

i'ype b ot individual a is deleted 

Parameters 

a = I’he individual 

a = i'he individual 


b = The new type (class) 

b = The old type (class) 

SPARQL used 
for detection 

SELECT ?a ?b WHERE { 

SELECT ?a ?b WHERE { 

GRAPH <v2> { ?a rdf:type ?b. 

GRAPH <vl> { ?a rdf:type ?b. 


FILTER (?b != rdfrClass && 

FILTER (?b != rdf:Class && 


?b != rdfs:Property && 

?b != rdfs:Property && 


?b != rdfs:Resource). } 

?b != rdfs : Resource). } 


FILTER NOT EXISTS { 

FILTER NOT EXISTS { 


GRAPH <vl> { ?a rdf:type ?b. 

GRAPH <v2> { ?a rdf:type ?b. 


FILTER (?b != rdf:Class && 

FILTER (?b != rdf:Class && 


?b != rdfs : Property && 

?b != rdfs : Property && 


?b != rdfs : Resource). } } 

} 

?b != rdfs : Resource) . } } 

} 

<5+ 

(a, rdf : type, 6) 

0 

5 - 

0 

(a, rdf : type, b) 

4^old 

- 

- 

0new 

(a, rdf : type, rdts : resource). 

(a, rdf : type, rdts : resource). 


FILTER (?b != rdPClass && 

FILTER (?b != rdPClass && 


?b != rdfs:Property && 

?b != rdfs:Property c&& 


?b != rdfs:Resource). 

?b != rdfs:Resource). 


Change 

Add_Froperty_lnstance( ai, a 2 , b) 

Delete _Froperty_lnstance( ai, a 2 , b) 

Intuition 

Add property instance ot property b 

Delete property instance ot property b 

Parameters 

a\ = i'he subject 

fli = The subject 


02 = The object 

02 = The object 


b = The property 

b = The property 

SPARQL used 

SELECT ?al ?b ?a2 WHERE { 

SELECT ?al ?b ?a2 WHERE { 

tor detection 

GRAPH <v2> { ?al ?b ?a2. 

GRAPH <vl> { ?al ?b ?a2. 


FILTER{?b!=rdfs:subClassOf && 

FILTER(?b!=rdfs:subClassOf && 


?b!=rdfs:subPropertyOf && 

?b!=rdfs:subPropertyOf && 


?b!=rdf:type && 

?b!=rdf:type && 


?b!=rdfs:comment && 

?b!=rdfs:comment && 


?b!=rdfs:label && 

?b!=rdfs:label && 


?b!=rdfs:domain && 

?b!=rdfs:domain && 


?b!=rdfs:range) } 

?b!=rdfs:range) } 


FILTER NOT EXISTS { 

FILTER NOT EXISTS { 


GRAPH <vl> { ?al ?b ?a2. 

GRAPH <v2> { ?al ?b ?a2. 


FILTER{?b!=rdfs:subClassOf && 

FILTER(?b!=rdfs:subClassOf && 


?b!=rdfs:subPropertyOf && 

?b!=rdfs:subPropertyOf && 


?b!=rdf:type && 

?b!=rdf:type && 


?b!=rdfs:comment && 

?b!=rdfs:comment && 


?b!=rdfs:label && 

?b!=rdfs:label && 


?b!=rdfs:domain && 

?b!=rdfs:domain && 


?b!=rdfs:range) } } 

} 

?b!=rdfs:range) } } 

} 

5 + 

(al, b, a2) 

0 

5 - 

0 

(al, 6, a2) 

0old 

- 

- 

0new 

FILTER (?b != rdts:subClassOf && 

FILTER (?b != rdfs:subClassOf && 


?b != rdfs: subPropertyOf && 

?b != rdfs:subPropertyOf && 


?b != rdPtype && ?b != rdfs:comment && 

?b != rdPtype && ?b != rdfs:comment && 


?b != rdfs:label && ?b != rdfs:domain && 

?b != rdfs:label && ?b != rdfs:domain && 


?b != rdfs:range) 

?b != rdfs:range) 






Change 

Add_Domain( a, b) 

Delete _Domain( a, b) 

Intuition 

Domain b of property a is added 

Domain b of property a is deleted 

Parameters 

a = I'he property 
b = The domain 

a = i'he property 
b = The domain 

SPARQL used 
for detection 

SELECT ?a ?b WHERE { 

GRAPH <v2> { 

?a rdfsrdomain ?b }. 

FILTER NOT EXISTS { 

GRAPH <vl> { 

?a rdfsrdomain ?b } } 

} 

SELECT ?a ?b WHERE { 

GRAPH <vl> { 

?a rdfsrdomain ?b }. 

FILTER NOT EXISTS { 

GRAPH <v2> { 

?a rdfsrdomain ?b } } 

} 

5+ 

(a, rdfs : domain, b) 

0 

s- 

0 

(a, rdfs : domain, 6) 

4^old 

- 

- 

4^new 

(a, rdt : type, rdf : property) 

(a, rdt : type, rdt : property) 


The changes Add_Range and Delete_Range are defined analogously with the exception that (a, rdfs : range, b) 
should be in J"*" ((5”) instead of (a, rdfs : domain, b). 


Change 

Add_Comment( a, b) 

Delete _Comment( a, b) 

Intuition 

Comment b of object a is added 

Comment b of object a is deleted 

Parameters 

a = I'he object 
b = The new comment 

a = i'he object 
b = The old comment 

SPARQL used 
for detection 

SELECT ?a ?b WHERE { 

GRAPH <v2> { 

?a rdfsr comment ?b }. 

FILTER NOT EXISTS { 

GRAPH <vl> { 

?a rdfsr comment ?b } } 

} 

SELECT ?a ?b WHERE { 

GRAPH <vl> { 

?a rdfsr comment ?b }. 

FILTER NOT EXISTS { 

GRAPH <v2> { 

?a rdfsr comment ?b } } 

} 

5+ 

(o, rdfs : comment, b) 

0 

s- 

0 

(a, rdfs : comment, 6) 

4^old 

- 

- 

^new 

- 

- 


Change 

Add_Label( a, b) 

Delete _Label( a, b) 

intuition 

Label b of object a is added 

Label b of object a is deleted 

Parameters 

a = 'i'he object 
b = The new comment 

a = i'he object 
b = The old comment 

SPARQL used 
for detection 

SELECT ?a ?b WHERE { 

GRAPH <v2> { 

?a rdfsr label ?b }. 

FILTER NOT EXISTS { 

GRAPH <vl> { 

?a rdfsr label ?b } } 

} 

SELECT ?a ?b WHERE { 

GRAPH <vl> { 

?a rdfsr label ?b }. 

FILTER NOT EXISTS { 

GRAPH <v2> { 

?a rdfsr label ?b } } 

} 

(5+ 

(a, rdfs : label, b) 

0 

s- 

0 

(a, rdfs : label, b) 

(bold 

- 

- 

4^new 

- 

- 




C. SIMPLE CHANGES FOR MULTIDIMEN¬ 
SIONAL DATA MODEL 

In this appendix, we list the simple changes refering to the multi¬ 
dimensional model. SPARQL queries have been expressed in RDF 
Data Cube vocabulary as soon as the data have been transformed 
respectively to this format. 

For each change and taking into account Definition[T]we present: 

• Its name. 

• The intuition it captures, described in terms of the RDF model. 

• Its parameters, and the intuition behind each parameter. 

• The SPARQL query which will be used for its detection. 

• The consumed added and deleted triples 5^,5“ C TP which 
are essentially sets of triple patterns. 


Change 

Add Codelist( c) 

Delete JUodelist{ c) 

Intuition 

Add a new codelist 

Delete a codelist 

Parameters 

c = I'he added codelist 

c = The deleted codelist 

SPARQL used 
for detection 

SELECT ?c WHERE { 

GRAPH <v2> { 

?c a skos:ConceptScheme. 

\ 

SELECT ?c WHERE { 

GRAPH <vl> { 

?c a skos:ConceptScheme. 

} 

FILTER NOT EXISTS { GRAPH <v2> { 

?c a skos:ConceptScheme. 

} 

} 

} 


; 

FILTER NOT EXISTS { GRAPH <vl> { 

?c a skos:ConceptScheme. 

} 

} 

} 

S+ 

(c, rdf : type, skos : ConceptScheme) 

0 

5- 

0 

(c, rdf : type, skos : ConceptScheme) 

(paid 

- 

- 

(Pnew 

- 

- 


Change 

Attach Codelist to Dimension( d, c) 

Detach Codelist^'rom Dimension( d, c) 

Intuition 

Assign a codelist to a dimension 

Disassociate a codelist from a dimension 

Parameters 

d = The dimension in which the codelist is attached 
c = The codelist which is attached to dimension 

d = The dimension in which the codelist is detached 
c = The codelist which is detached from dimension 

SPARQL used 

for detection 

SELECT ?d ?C WHERE { 

GRAPH <v2> { 

?d qb:codeList ?c. 

SELECT ?d ?C WHERE { 

GRAPH <vl> { 

?d qbrcodeList ?c. 

} 

FILTER NOT EXISTS { GRAPH <v2> { 

?d qbrcodeList ?c. 

} 

} 

} 


; 

FILTER NOT EXISTS { GRAPH <vl> { 

?d qb:codeList ?c. 

} 

} 

} 

<5+ 

(d, qb : codeList, c) 

0 

5 - 

0 

{d, qb : codeList, c) 

(Pold 

- 

- 

P^new 

- 

- 






















Change 

Add_Dimension( d) 

Delete _Dimension( d) 

Intuition 

Add a new dimension (not assigned to a fact table) 

Delete a dimension 

Parameters 

d = fhe added dimension 

d = 'I'he deleted dimension 

SPARQL used 
for detection 

SELECT ?d WHERE { 

GRAPH <v2> { 

?d a qb:DimensionProperty. 

} 

FILTER NOT EXISTS { GRAPH <vl> { 

?d a qb:DimensionProperty. 

} 

} 

} 

SELECT ?d WHERE { 

GRAPH <vl> { 

?d a qb:DimensionProperty. 

} 

FILTER NOT EXISTS { GRAPH <v2> { 

?d a qb:DimensionProperty. 

} 

} 

} 


(D, rdf : type, qb : DimensionProperty) 

0 

s- 

0 

(_D, rdf : type, qb : DimensionProperty) 

<t>old 

- 

- 

^new 

- 

- 


Change 

Attach_Datatype_to_Dimension(d, t) 

Detach_DatatypeJ^rom_Dimension( d, t) 

Intuition 

Associate a datatype with an existing dimension 

Disassociate a datatype from an existing dimension 

Parameters 

d = 'fhe dimension in which the datatype is attached 
t = The datatype which is attached to dimension 

d = 'I'he dimension in which the datatype is de¬ 
tached 

t = The datatype which is detached from dimension 

SPARQL used 
for detection 

SELECT ?d ?t WHERE { 

GRAPH <v2> { 

?d a qb:DimensionProperty. 

?d rdfs:range ?t. 

\ 

SELECT ?d ?t WHERE { 

GRAPH <vl> { 

?d a qb:DimensionProperty. 

?d rdfs:range ?t. 

1 


1 

FILTER NOT EXISTS { GRAPH <vl> { 

?d rdfs:range ?t. 

} 

} 

} 

; 

FILTER NOT EXISTS { GRAPH <v2> { 

?d rdfs:range ?t. 

} 

} 

} 

<5+ 

(d, rdfs : range, t) 

0 

5- 

0 

(d, rdfs : range, t) 

4 ^old 

- 

[d, rdf : type, qb : DimensionProperty) 

4 ^new 

(d, rdf : type, qb : DimensionProperty) 

- 


Change 

Attach _Attr_to_Dimension( d, attr) 

Detach_AttrJ^rom_Dimension(d, attr) 

Intuition 

Associate an attribute property to a dimension 

Disassociate an attribute property from a dimension 

Parameters 

d = 'fhe dimension in which the atribute is attached 
attr = The attribute which is attached to dimension 

d = I'he dimension in which the attribute is detached 
attr = The attribute which is detached from dimen¬ 
sion 

SPARQL used 
for detection 

SELECT ?d ?attr WHERE { 

GRAPH <v2> { 

?d a qb:DimensionProperty. 

?d qb:attribute ?attr. 

SELECT ?d ?attr WHERE { 

GRAPH <vl> { 

?d a qb:DimensionProperty . 

?d qb:attribute ?attr. 

1 


1 

FILTER NOT EXISTS { GRAPH <vl> { 

?d qb:attribute ?attr. 

} 

} 

} 

; 

FILTER NOT EXISTS { GRAPH <v2> { 

?d qb:attribute ?attr. 

} 

} 

} 

5+ 

(d, qb : attribute, attr) 

0 

5- 

0 

(d, qb : attribute, attr) 

4^old 

- 

(d, rdf : type, qb : DimensionProperty) 

4^new 

(d, rdf : type, qb : DimensionProperty) 

- 




Change 

Add_Observation{ o) 

Delete _Observation( o) 

Intuition 

Add an observation entity 

Delete an observation entity 

Parameters 

o = I'he observation which is added 

0 = 'I'he observation which is deleted 

SPARQL used 
for detection 

SELECT ?o WHERE { 

GRAPH <v2> { 

?o a qb:Observation. 

} 

FILTER NOT EXISTS { GRAPH <vl> { 

?o a qbrObservation. 

} 

} 

} 

SELECT ?o WHERE { 

GRAPH <vl> { 

?o a qb : Observation. 

} 

FILTER NOT EXISTS { GRAPH <v2> { 

?o a qb : Observation. 

} 

} 

} 


(o, rdf : type, qb : Observation) 

0 

s- 

0 

(o, rdf : type, qb : Observation) 

<t>old 

- 

- 

0 new 

- 

- 


Change 

Attach_Observation_to_FT( o, ft) 

Detach_Observation_f'rom_FT( o, ft) 

Intuition 

Associate an observation to a tact table 

Disassociate an observation from a tact table 

Parameters 

o = I'he observation which is attached to fact table 
ft = The fact table 

0 = I’he observation which is detached from fact 
table 

ft = The fact table 

SPARQL used 
for detection 

SELECT ?o ?ft WHERE { 

GRAPH <v2> { 

?o qbrdataSet ?ds. 

?ds qb:structure ?ft. 

SELECT ?o ?ft WHERE { 

GRAPH <vl> { 

?o qb:dataSet ?ds. 

?ds qb:structure ?ft. 

1 


1 

FILTER NOT EXISTS { GRAPH <vl> { 

?o qbrdataSet ?ds. 

?ds qb:structure ?ft. 

} 

} 

} 

; 

FILTER NOT EXISTS { GRAPH <v2> { 

?o qb:dataSet ?ds. 

?ds qb:structure ?ft. 

} 

} 

} 


(o, qb : dataSet, ds), {ds, qb : structure, ft) 

0 

s- 

0 

(o, qb : dataSet, ds), {ds, qb : structure, ft) 

4> 

- 

- 






Change 

Add_Measure_Value_to_Observation(o, m, v) 

Delete_Measure_Value^'rom_Observation(o^ m, v) 

Intuition 

Add value to a measure in a specific observation 

Delete a value from an observation 

Parameters 

0 = 'I'he observation 

0 = The observation 


m = The measure on which the observation refers 

m = The measure on which the observation refers 


V = The value of the measure 

V = The value of the measure 

SPARQL used 
for detection 

SELECT ?o ?m ?v WHERE { 

SELECT ?o ?m ?v WHERE { 

GRAPH <v2> { 

GRAPH <vl> { 


?o qbrdataSet ?ds . 

?o qbrdataSet ?ds. 


?ds qb:structure ?ft. 

?ds qb:structure ?ft. 


?ft qb:component ?cs. 

?ft qb:component ?cs. 


?cs qb:measure ?m. 

?cs qbrmeasure ?m. 


?m a qb:MeasureProperty. 

?m a qb:MeasureProperty. 


?m rdfs:range ?v. 

?m rdfs:range ?v. 

i 


; 

FILTER NOT EXISTS { GRAPH <vl> { 

j 

FILTER NOT EXISTS { GRAPH <v2> { 


?o qbrdataSet ?ds. 

?o qbrdataSet ?ds. 


?ds qb:structure ?ft. 

?ds qb:structure ?ft. 


?ft qb:component ?cs. 

?ft qb:component ?cs. 


?cs qbrmeasure ?m. 

?cs qbrmeasure ?m. 


?m a qbrMeasureProperty. 

?m a qb:MeasureProperty. 


?m rdfs:range ?v. 

} 

} 

} 

?m rdfs:range ?v. 

} 

} 

} 

<5+ 

{o,qb : dataSetyds), {ds,qb : structure, ft), 
(ft,qb : component, cs), {cs,qb : measure, m), 
(m, rdfs : range, v) 

0 

< 5 - 

0 

( 0 , qb : dataSet, ds), {ds, qb : structure, ft), 
(ft, qb : component, cs), (cs, qb : measure, m). 



(m, rdfs : range, v) 

4 ^old 

- 

(m, rdf : type, qb : MeasureProperty) 

4^new 

(m, rdf : type, qb : Measure Property) 

- 


Change 

Add_Dimension_Value_to_Observation( 0 , d, v) 

Delete_Dimension_Value^'rom_Observation(o, d,i) 

Intuition 

Add value to a dimension in a specihc observation 

Delete value from a dimension m an observation 

Parameters 

0 = The observation 

d = The dimension on which the observation refers 

V = The value of the dimension 

0 = The observation 

d = The dimension on which the observation refers 

V = The value of the dimension 

SPARQL used 
for detection 

SELECT ?o ?d ?v WHERE { 

GRAPH <v2> { 

?o qbrdataSet ?ds. 

?ds qb:structure ?ft. 

?ft qb:component ?cs. 

?cs qbrdimension ?d. 

?d a qb : DimensionProperty. 

?d rdfs:range ?v. 

} 

FILTER NOT EXISTS { GRAPH <vl> { 

?o qbrdataSet ?ds . 

?ds qb:structure ?ft. 

?ft qb:component ?cs. 

?cs qbrdimension ?d. 

?d a qb:DimensionProperty. 

?d rdfs:range ?v. 

} 

} 

} 

SELECT ?o ?d ?v WHERE { 

GRAPH <vl> { 

?o qbrdataSet ?ds . 

?ds qb:structure ?ft. 

?ft qb:component ?cs. 

?cs qbrdimension ?d. 

?d a qb : DimensionProperty. 

?d rdfs:range ?v. 

} 

FILTER NOT EXISTS { GRAPH <v2> { 

?o qbrdataSet ?ds. 

?ds qb:structure ?ft. 

?ft qb:component ?cs. 

?cs qbrdimension ?d. 

?d a qb : DimensionProperty. 

?d rdfs:range ?v. 

} 

} 

} 

<5+ 

(o,qb : dataSetyds), (ds,qb : structure, ft), 
(ft, qb : component, cs), (cs, qb : 

dimension, d), (d, rdfs : range, v) 

0 

< 5 - 

0 

(o,qb : dataSetyds), (ds,qb : structure, ft), 
(ft,qb : component, cs), (cs,qb : 

dimension, d), (d, rdfs ; range,?;) 

(j^oid 

- 

[d, rdf : type, qb : DimensionProperty) 

4^new 

(d, rdf : type, qb : DimensionProperty) 

- 




Change 

Add_Hierarchy( h) 

Delete _Hierarchy( h) 

Intuition 

Add a new hierarchy 

Delete an hierarchy 

Parameters 

h = The added hierarchy 

h = i'he deleted hierarchy 

SPARQL used 
for detection 

SELECT ?h WHERE { 

GRAPH <v2> { 

?h a qb:HierarchicalCodeList. 

FILTER NOT EXISTS 
{ ?h a skos:ConceptScheme. } 

\ 

SELECT ?h WHERE { 

GRAPH <vl> { 

?h a qb:HierarchicalCodeList. 

FILTER NOT EXISTS 
{ ?h a skos:ConceptScheme. } 

1 


; 

FILTER NOT EXISTS { GRAPH <vl> { 

?h a qb:HierarchicalCodeList. 

FILTER NOT EXISTS 
{ ?h a skos:ConceptScheme. } 

} 

} 

} 

j 

FILTER NOT EXISTS 
{ GRAPH <v2> { 

?h a qb:HierarchicalCodeList. 

FILTER NOT EXISTS 
{ ?h a skos:ConceptScheme. } 

} 

} 

} 


{h, rdf : type, qb : HierarchicalCodeList) 

0 

s- 

0 

(h, rdf : type, qb : HierarchicalCodeList) 

(t>old 


FILTER NOT EXISTS 
{ ?h a skos:ConceptScheme. } 

0 new 

FILTER NOT EXISTS 
{ ?h a skos:ConceptScheme. } 



Change 

Attach_Hierarchy Jo_Dimension( d, fi) 

Detach_HierarchyJ'romJ)imension(d, k) 

Intuition 

Associate an hierarchy to a dimension 

Disassociate an hierarchy from a dimension 

Parameters 

d = i'he dimension in which the hierarchy is at¬ 
tached 

h = The hierarchy which is attached to dimension 

d = 'I'he dimension in which the hierarchy is de¬ 
tached 

h = The hierarchy which is detached from dimen¬ 
sion 

SPARQL used 
for detection 

SELECT ?d ?h WHERE { 

GRAPH <v2> { 

?d qbrcodeList ?h. 

?h a qb:HierarchicalCodeList. 

FILTER NOT EXISTS 
{ ?h a skos:ConceptScheme. } 

\ 

SELECT ?d ?h WHERE { 

GRAPH <vl> { 

?d qbrcodeList ?h. 

?h a qb:HierarchicalCodeList. 

FILTER NOT EXISTS 
{ ?h a skos : ConceptScheme. } 

1 


1 

FILTER NOT EXISTS { GRAPH <vl> { 

?d qbrcodeList ?h. 

} 

} 

} 

J 

FILTER NOT EXISTS { GRAPH <v2> { 

?d qb:codeList ?h. 

} 

} 

} 


(d, qb : codeList, h) 

0 

5- 

0 

(d, qb : codeList, h) 

<t>old 

- 

(h, rdf : type, qb : HierarchicalCodeList) 

4^new 

(h, rdf : type, qb : HierarchicalCodeList) 

- 





Change 

Add_lnstance(i) 

Delete _lnstance{ i) 

Intuition 

Add a new instance 

Delete an instance 

Parameters 

i = 'I'he added instance 

i = i'he deleted instance 

SPARQL used 
for detection 

SELECT ?i WHERE { 

GRAPH <v2> { 

?i a skos:Concept. 

} 

FILTER NOT EXISTS { GRAPH <vl> { 

?i a skos:Concept. 

} 

} 

} 

SELECT ?i WHERE { 

GRAPH <vl> { 

?i a skos:Concept. 

} 

FILTER NOT EXISTS { GRAPH <v2> { 

?i a skos:Concept. 

} 

} 

} 

<5+ 

(i, rdf : type, skos : Concept) 

0 

s- 

0 

(i, rdf : type, skos : Concept) 

4^old 

- 

- 

4^new 

- 

- 


Change 

Attach_lnstance_to_Codelist( c, i) 

Detach_lnstance_f'rom_Codelist( c^i) 

Intuition 

Associate a new instance with a codelist 

Disassociate an instance from a codelist 

Parameters 

c = i'he codelist in which the instance is attached 
i = The instance which is attached to codelist 

c = 'i'he codelist in which the instance is attached 
i = The instance which is attached to codelist 

SPARQL used 
for detection 

SELECT ?c ?i WHERE { 

GRAPH <v2> { 

?i a skos:ConceptScheme. 

?c skos:inScheme ?i. 

SELECT ?c ?i WHERE { 

GRAPH <vl> { 

?i a skos:ConceptScheme. 

?c skos:inScheme ?i. 

1 


1 

FILTER NOT EXISTS { GRAPH <vl> { 

?c skos : inScheme ?i. 

} 

} 

} 

1 

FILTER NOT EXISTS { GRAPH <v2> { 

?c skos : inScheme ?i. 

} 

} 

} 


[i, skos : inScheme, c) 

0 

5- 

0 

(i, skos : inScheme, c) 

<t>old 

- 

(c, rdf : type, skos : ConceptScheme) 

4^new 

(c, rdf : type, skos : ConceptScheme) 

- 


Change 

Attach_Instance_to_Hierarchy( h,i) 

Detach_lnstance_f'rom_Hierarchy(h, i) 

intuition 

Associate a new instance with a hierarchy 

Disassociate a new instance from a hierarchy 

Parameters 

h = The hierarchy in which the instance is attached 
i = The instance which is attached to hierarchy 

h = i'he hierarchy in which the instance is attached 
i = The instance which is attached to hierarchy 

SPARQL used 
for detection 

SELECT ?h ?i WHERE { 

GRAPH <v2> { 

?h a qb: HierarchicalCodeList. 

?i skos:inScheme ?h. 

SELECT ?h ?i WHERE { 

GRAPH <vl> { 

?h a qb: HierarchicalCodeList. 

?i skos:inScheme ?h. 

1 


1 

FILTER NOT EXISTS { GRAPH <vl> { 

?i skos : inScheme ?h. 

} 

} 

} 

; 

FILTER NOT EXISTS { GRAPH <v2> { 

?i skos : inScheme ?h. 

} 

} 

} 

(5+ 

(i, skos : inScheme, h) 

0 

s- 

0 

{i, skos : inScheme, h) 

4 ^old 

- 

[h, rdf : type, qb : HierarchicalCodeList) 

4^new 

(h, rdf : type, <76 : HierarchicalCodeList) 

- 





Change 

Attach_Instance_to_Farent(i, p) 

Detach_Instance_to_Farent(i, p) 

Intuition 

Associate an instance with its parent 

Disassociate an instance from its parent 

Parameters 

i = 'I'he instance 

p = The parent which is added to instance 

i = i'he instance 

p = The parent which is deleted from instance 

SPARQL used 
for detection 

SELECT ?i ?p WHERE { 

GRAPH <v2> { 

?i skos:broaderTransitive ?p. 

} 

FILTER NOT EXISTS { GRAPH <vl> { 

?i skos : broaderTransitive ?p. 

} 

} 

} 

SELECT ?i ?p WHERE { 

GRAPH <vl> { 

?i skos:broaderTransitive ?p. 

} 

FILTER NOT EXISTS { GRAPH <v2> { 

?i skos:broaderTransitive ?p. 

} 

} 

} 

(5+ 

(i,skos : broaderTransitive, p) 

0 

s- 

0 

{iySkos : broaderTransitive, p) 

(t>old 

- 

- 

0 new 

- 

- 


Change 

Add_Measure( m) 

Delete _Measure{ m) 

Intuition 

Add a new measure 

Delete a measure 

Parameters 

m = i'he measure which is added 

m = 'i'he measure which is deleted 

SPARQL used 
for detection 

SELECT ?m WHERE { 

GRAPH <v2> { 

?m a qb:MeasureProperty. 

\ 

SELECT ?m WHERE { 

GRAPH <vl> { 

?m a qb:MeasureProperty. 

1 


1 

FILTER NOT EXISTS { GRAPH <vl> { 

?m a qb:MeasureProperty. 

} 

} 

} 

j 

FILTER NOT EXISTS { GRAPH <v2> { 

?m a qb:MeasureProperty. 

} 

} 

} 

5+ 

(m, rdf : type, qb : MeasureProperty) 

0 

s- 

0 

(m, rdf : type, qb : MeasureProperty) 

^old 

- 

- 

0 new 

- 

- 


Change 

Attach_Type_to_Measure(t, m) 

Detach_Type^'rom_Measure(t, m) 

intuition 

Associate a new datatype to a measure 

Disassociate a datatype from a measure 

Parameters 

t = i'he added type to measure 
m = The measure in which the type is added 

t = 'i'he deleted type from measure 
m = The measure in which the type is deleted 

SPARQL used 
for detection 

SELECT ?m ?t WHERE { 

GRAPH <v2> { 

?m a qb :MeasureProperty. 

?m rdfs:range ?t. 

\ 

SELECT ?m ?t WHERE { 

GRAPH <vl> { 

?m a qb: MeasureProperty. 

?m rdfs:range ?t. 

i 


; 

FILTER NOT EXISTS { GRAPH <vl> { 

?m rdfs:range ?t . 

} 

} 

} 

J 

FILTER NOT EXISTS { GRAPH <v2> { 

?m rdfs:range ?t. 

} 

} 

} 


(m, rdfs : range, t) 

0 

5- 

0 

(m, rdfs : range, t) 

(j^oid 

- 

(m, rdf : type, qb : MeasureProperty) 

4^new 

(m, rdf : type, qb : MeasureProperty) 

- 



Change 

Add_Fact_Table( ft) 

Delete _t'actjrable{ ft) 

Intuition 

Add a new fact table 

Delete a fact table 

Parameters 

ft = I'he fact table is added 

ft = i'he fact table which is deleted 

SPARQL used 
for detection 

SELECT ?ft WHERE { 

GRAPH <v2> { 

?ft a qb:DataStructureDefinition. 

} 

FILTER NOT EXISTS { GRAPH <vl> { 

?ft a qb:DataStructureDefinition. 

} 

} 

} 

SELECT ?ft WHERE { 

GRAPH <vl> { 

?ft a qb:DataStructureDefinition. 

} 

FILTER NOT EXISTS { GRAPH <v2> { 

?ft a qb:DataStructureDefinition. 

} 

} 

} 


{ft, rdf : type, qb : DataStructureDef inition) 

0 

s- 

0 

{ft, rdf : type, qb : DataStructureDef inition) 

4^old 

- 

- 

(pnew 

- 

- 




Change 

Intuition 

Parameters 


SPARQL used 
for detection 


Add_Label( s, o) 

Add a new label 

s = The subject in which the label is added 
o = The added label 

SELECT ?s ?0 WHERE { 

GRAPH <v2> { 

? s ?p ?o. 

filter (?p = rdfsrlabel). 

} 

FILTER NOT EXISTS { GRAPH <vl> { 
? s ?p ?o 


(a, rdfs : label, b) 


Delete_Label( s, o) 

Delete a label 

s = The subject in which the label is deleted 
o = The deleted label 

SELECT ?s ?0 WHERE { 

GRAPH <vl> { 

? s ?p ?o. 

filter {?p = rdfs:label). 

} 

FILTER NOT EXISTS { GRAPH <v2> { 
? s ?p ?o 
} 

} 

} 


(a, rdfs : label, b) 


'new 




Change 

Attach_Measure_to_t'actjrable(m, ft) 

Detach_Measure_f'rom_t'actjrable( m, ft) 

Intuition 

Associate a measure property to tact table 

Disassociate a measure property trom a tact table 

Parameters 

m = i'he added measure to tact table 

ft = The fact table in which the measure is added 

m = 'I'he deleted measure to fact table 

ft = The fact table in which the measure is deleted 

SPARQL used 
for detection 

SELECT ?ft ?m WHERE { 

GRAPH <v2> { 

?ft qb:component ?cs. 

?cs qb:measure ?m. 

SELECT ?ft ?m WHERE { 

GRAPH <vl> { 

?ft qb:component ?cs. 

?cs qb:measure ?m. 

1 


1 

FILTER NOT EXISTS { GRAPH <vl> { 

?ft qb:component ?cs. 

?cs qb:measure ?m. 

} 

} 

} 

; 

FILTER NOT EXISTS { GRAPH <v2> { 

?ft qb:component ?cs. 

?cs qb:measure ?m. 

} 

} 

} 

(5+ 

(ft, qb : component, cs), (cs, qb : measure, m) 

0 

s- 

0 

(ft, qb : component, cs), (cs, qb : measure, m) 

4^old 

- 

- 

^new 

- 

- 


Change 

Attach_Dimension_to_Factjrable( d, f'l) 

Detach_Dimension^'rom_Fact_Table( d, ft) 

Intuition 

Associate a dimension property to fact table 

Disassociate a dimension property from a fact table 

Parameters 

d = fhe added dimension to fact table 

ft = The fact table in which the dimension is added 

d, = 'I'he deleted dimension to fact table 

ft = The fact table in which the dimension is 

deleted 

SPARQL used 
for detection 

SELECT ?d ?ft WHERE { 

GRAPH <v2> { 

?ft qb:component ?cs. 

?cs qb:dimension ?d. 

SELECT ?d ?ft WHERE { 

GRAPH <vl> { 

?ft qb:component ?cs. 

?cs qb:dimension ?d. 

1 


1 

FILTER NOT EXISTS { GRAPH <vl> { 

?ft qb:component ?cs. 

?cs qb:dimension ?d. 

} 

} 

} 

; 

FILTER NOT EXISTS { GRAPH <v2> { 

?ft qb:component ?cs. 

?cs qb:dimension ?d. 

} 

} 

} 

5+ 

(ft, qb : component, es), (cs, qb : 

dimension, d) 

0 

5- 

0 

(ft,qb : component, cs), (cs,qb : 

dimension, d) 

(fold 

- 

- 

(pnew 

- 

- 


Change 

Add_Attribute( attr) 

Delete _Attribute( attr) 

Intuition 

Add a new attribute 

Delete an attribute 

Parameters 

attr = 'I'he attribute which is added 

attr = 'fhe attribute which is deleted 

SPARQL used 
for detection 

SELECT ?attr WHERE { 

GRAPH <v2> { 

?attr a qb:AttributeProperty. 

\ 

SELECT ?attr WHERE { 

GRAPH <vl> { 

?attr a qb:AttributeProperty. 

1 


/ 

FILTER NOT EXISTS { GRAPH <vl> { 
?attr a qb : AttributeProperty. 

} 

} 

} 

J 

FILTER NOT EXISTS { GRAPH <v2> { 
?attr a qb : AttributeProperty. 

} 

} 

} 

5+ 

(attr, rdf : type, qb : AttributeProperty) 

0 

s- 

0 

(attr, rdf : type, qb : AttributeProperty) 

<t>old 

- 

- 

(fnew 

- 

- 





Change 

Attach_Attr_to_Measure(attr^ m) 

Detach_Attr_f 'rom_Measure(attr^ m) 

Intuition 

Associate an attribute with an existing measure 

Disassociate an attribute from a measure 

Parameters 

attr = i'he attribute which is attached to measure 
m = The measure which is attached 

attr = i'he attribute which is detached from mea¬ 
sure 

m = The measure in which is the measure is de- 
tatched 

SPARQL used 
for detection 

SELECT ?attr ?m WHERE { 

GRAPH <v2> { 

?m a qb:MeasureProperty. 

?m qb:attribute ?attr. 

SELECT ?attr ?m WHERE { 

GRAPH <vl> { 

?m a qb:MeasureProperty. 

?m qb:attribute ?attr. 

1 


1 

FILTER NOT EXISTS { GRAPH <vl> { 

?m qb:attribute ?attr. 

} 

} 

} 

; 

FILTER NOT EXISTS { GRAPH <v2> { 

?m qb:attribute ?attr. 

} 

} 

} 


(m, qh : attribute, attr) 

0 

s- 

0 

(m, qb : attribute, attr) 

4^old 

- 

(m, rdf : type, qb : MeasureProperty) 

4^new 

(m, rdf : type, qb : MeasureProperty) 

- 


Change 

Attach_Observation_to_Dataset( o, ds) 

Detach_Observation^'rom_Dataset( o, ds) 

Intuition 

Associate an observation with an existing dataset 

Disassociate an observation from a dataset 

Parameters 

o = The observation which is attached to dataset 
ds = The dataset which in which the observation is 
attached 

o = The observation which is detached from dataset 
ds = The dataset in which is the observation is de- 
tatched 

SPARQL used 
for detection 

SELECT ?o ?ds WHERE { 

GRAPH <v2> { 

?o qb:dataSet ?ds. 

SELECT ?o ?ds WHERE { 

GRAPH <vl> { 

?o qb:dataSet ?ds. 

1 


1 

FILTER NOT EXISTS { GRAPH <vl> { 

?o qb:dataSet ?ds. 

} 

} 

} 

; 

FILTER NOT EXISTS { GRAPH <v2> { 

?o qb:dataSet ?ds. 

} 

} 

} 

5+ 

(o, qb : dataSet, ds) 

0 

s- 

0 

(o, qb : dataSet, ds) 

(t>old 

- 

- 

4^new 

- 

- 





Change 

Add_lnscheme(x^ s) 

Delete_Inscheme(x, s) 

Intuition 

Add a scheme in a term 

Delete a scheme from a term 

Parameters 

X = i'he term which is associated to the scheme 

X = i'he term which is deleted from associated 


s = The associated scheme 

scheme 

s = The associated scheme 

SPARQL used 
for detection 

SELECT ?x ?s WHERE { 

SELECT ?x ?s WHERE { 

GRAPH <v2> { 

GRAPH <vl> { 


FILTER NOT EXISTS { { 

FILTER NOT EXISTS { 


?s rdf:type skos : ConceptScheme. } 

{?s rdf:type 


UNION 

skos:ConceptScheme. } 


{ ?s rdf:type 

UNION 


qb :HierarchicalCodeList.} 

{?s rdf:type 


} 

qb: HierarchicalCodeList. } 


?x skos : inScheme ?s. 

} 


} 

?x skos : inScheme ?s. 


FILTER NOT EXISTS { GRAPH <vl> { 

} 


?x skos : inScheme ?s. 

FILTER NOT EXISTS { GRAPH <v2> { 


} 

} 

} 

?x skos : inScheme ?s. 

} 

} 

} 


{x, skos : inScheme, s) 

0 

s- 

0 

(x, skos : inScheme, s) 

(t>old 


FILTER NOT EXISTS { 

{?s rdf:type skos : ConceptScheme. } 
UNION 

{?s rdf:type 

qb: HierarchicalCodeList. } 

} 

0new 

FILTER NOT EXISTS { 

{ ?s rdf:type 

skos : ConceptScheme. } 

UNION 

{ ?s rdf:type 

qb: HierarchicalCodeList. } 

} 





Change 

Add_(Jnknown_Froperty( s, p, 0 ) 

Delete_lJnknown_Froperty( s, p, 0 ) 

Intuition 

Add a new (unknown) property with specihed subject and 

Delete a property 


object related 


Parameters 

s = I'he subject in which the property is added 

s = 'I'he subject in which the property is deleted 


p = The property 

p = The property 


0 = The object which is related with the subject via the prop¬ 

0 = The object which is related with the subject via the prop¬ 


erty 

erty 

SPARQL used 

SELECT ?s ?p ?0 WHERE { 

SELECT ?s ?p ?0 WHERE { 

for detection 

GRAPH <v2> { 

GRAPH <vl> { 


{FILTER NOT EXISTS 

{FILTER NOT EXISTS 


{?p rdfs:subPropertyOf rdfs:label}} 

{?p rdfs:subPropertyOf rdfs:label}} 


UNION 

UNION 


{FILTER (?p != rdfs:label).} 

{FILTER (?p != rdfs:label).} 


? s ?p ? 0 . 

?s ?p ? 0 . 


FILTER(?p != rdfsrlabel). 

FILTER(?p != rdfs:label). 


FILTER{?p != rdfsrrange). 

FILTER(?p != rdfs:range). 


FILTER(?p != skos:inScheme). 

FILTER(?p != skos:inScheme). 


FILTER(?p != skosrbroaderTransitive). 

FILTER(?p != skos:broaderTransitive). 


FILTER{?p != qb:codeList). 

FILTER(?p != qb:codeList). 


FILTER(?p != qb:component). 

FILTER(?p != qb:component). 


FILTER(?p != qb:dimension). 

FILTER(?p != qb:dimension). 


FILTER{?p != qb:measure). 

FILTER(?p != qb:measure). 


FILTER(?p != qb:attribute). 

FILTER(?p != qb:attribute). 


FILTER(?p != qb:dataSet). 

FILTER(?p != qb:dataSet). 


FILTER{?p != qb:structure). 

FILTER(?p != qb:structure). 


FILTER(?p != rdf:type 

FILTER(?p != rdf:type 


II skos:Concept). 

1 skos:Concept). 


FILTER (?p != rdf:type 

FILTER (?p != rdf:type 


11 skos:ConceptScheme). 

1 skos:ConceptScheme). 


FILTER (?p != rdf:type 

FILTER (?p != rdf:type 


11 qb:AttributeProperty). 

1 1 qb:AttributeProperty) . 


FILTER (?p != rdf:type 

FILTER (?p != rdf:type 


11 qb:CodedProperty). 

1 qb:CodedProperty) . 


FILTER (?p != rdf:type 

FILTER (?p != rdf:type 


11 qb:DimensionProperty). 

1 qb:DimensionProperty). 


FILTER (?p != rdf:type 

FILTER (?p != rdf:type 


11 qb:DataStructureDefinition). 

1 qb:DataStructureDefinition) . 


FILTER (?p != rdf:type 

FILTER {?p != rdf:type 


11 qb:HierarchicalCodeList). 

1 qb:HierarchicalCodeList). 


FILTER (?p != rdf:type 

FILTER (?p != rdf:type 


11 qb:Observation). } 

1 qb:Observation). } 


FILTER NOT EXISTS 

FILTER NOT EXISTS 


{ GRAPH <vl> { 

{ GRAPH <vl> { 


? s ?p ? 0 . 

} 

} 

?s ?p ? 0 . 

} 

} 

5+ 

(s, p, 0 ) 

0 

5 - 

0 

(s, p, 0 ) 






{FILTER NOT EXISTS 

{?p rdfs:subPropertyOf rdfs:label}} 
UNION 

(FILTER (?p != rdfs:label).} 

? s ?p ?o. 

FILTER(?p != rdfs:label). 

FILTER(?p != rdfs:range). 

FILTER(?p != skos:inScheme). 
FILTER(?p != skos:broaderTransitive 
FILTER(?p != qbrcodeList). 

FILTER(?p != qb:component). 
FILTER(?p != qb:dimension). 
FILTER(?p != qbrmeasure). 

FILTER(?p != qb:attribute). 
FILTER(?p != qbrdataSet). 

FILTER(?p != qb:structure). 

FILTER(?p != rdf:type 
I I skos:Concept) . 

FILTER (?p != rdf:type 
I I skos:ConceptScheme) . 

FILTER (?p != rdf:type 
I I qb:AttributeProperty) . 

FILTER (?p != rdf:type 
I I qb:CodedProperty) . 

FILTER (?p != rdf:type 
I I qb:DimensionProperty) . 

FILTER (?p != rdf:type 
I I qb:DataStructureDefinition) . 
FILTER (?p != rdf:type 
I I qb:HierarchicalCodeList) . 

FILTER (?p != rdf:type 
I I qb:Observation) . 


(FILTER NOT EXISTS 

{?p rdfs:subPropertyOf rdfs:label}} 
UNION 

(FILTER (?p != rdfs:label).} 

? s ?p ?o. 

FILTER(?p != rdfs:label). 

FILTER(?p != rdfs:range). 

FILTER(?p != skos:inScheme). 
FILTER(?p != skos:broaderTransitive 
FILTER(?p != qb:codeList). 

FILTER(?p != qb:component). 

FILTER(?p != qb:dimension). 
FILTER(?p != qb:measure). 

FILTER(?p != qb:attribute). 
FILTER(?p != qb:dataSet). 

FILTER{?p != qb:structure). 

FILTER(?p != rdf:type 
II skos:Concept). 

FILTER (?p != rdf:type 
I I skos:ConceptScheme) . 

FILTER (?p != rdf:type 
I I qb:AttributeProperty) . 

FILTER (?p != rdf:type 
I I qb:CodedProperty) . 

FILTER (?p != rdf:type 
I I qb:DimensionProperty) . 

FILTER (?p != rdf:type 
I I qb:DataStructureDefinition) . 
FILTER (?p != rdf:type 
I I qb:HierarchicalCodeList) . 

FILTER (?p != rdf:type 
I I qb:Observation) . 






Change 

Add_Generic_Datatype(x, t) 

Intuition 

Add a data type to a given subject 

Parameters 

X = i'he subject in which the datatype is added 
t = The added datatype 

SPARQL used 
for detection 

SELECT ?x ?t WHERE { 

GRAPH <v2> { 

?x rdfs:range ?t . 

} 

FILTER NOT EXISTS { GRAPH <vl> { 
?x rdfs:range ?t. 

} 

} 

} 


(x, rdfs ; range, t) 

< 5 - 

0 

0 old 

- 


'new 


Delete_Generic_Datatype(x, t) 

Delete a data type trom a subject 
X = The subject in which the datatype is deleted 
t = The deleted datatype 

SELECT ?x ?t WHERE { 

GRAPH <vl> { 

?x rdfs:range ?t. 

} 

FILTER NOT EXISTS { GRAPH <v2> { 
?x rdfs:range ?t. 

} 

} 

} 


0 


(a;, rdfs : range, t) 




Change 

Add_Generic_Attnbute(x, attr) 

Delete_Generic_Attribute(x, attr) 

Intuition 

Add a generic attribute to a given subject 

Delete a generic attribute from a subject 

Parameters 

X = i'he subject in which the attribute is added 
attr = The added attribute 

X = The subject in which the attribute is deleted 
attr = The deleted attribute 

SPARQL used 
for detection 

SELECT ?x ?attr WHERE { 

GRAPH <v2> { 

FILTER NOT EXISTS { 

{?attr rdf:type 

qb:DimensionProperty.} 

UNION 

{?attr rdf:type 
qb:MeasureProperty.} 

UNION 

{?attr rdf:type 
qb:CodedProperty.} 

\ 

SELECT ?x ?attr WHERE { 

GRAPH <vl> { 

FILTER NOT EXISTS { 

{?attr rdf:type 

qb:DimensionProperty.} 

UNION 

{?attr rdf:type 
qb:MeasureProperty.} 

UNION 

{?attr rdf:type 
qb:CodedProperty.} 

1 


; 

?x qb:attribute ?attr. 

J 

?x qb:attribute ?attr. 

1 


1 

FILTER NOT EXISTS { GRAPH <vl> { 

?x qb:attribute ?attr. 

} 

} 

} 

; 

FILTER NOT EXISTS { GRAPH <v2> { 

?x qb:attribute ?attr. 

} 

} 

} 

5+ 

(*, qb : attribute, attr) 

0 

s- 

0 

(x, qb : attribute, attr) 



FILTER NOT EXISTS { 

{?attr rdf:type 

qb:DimensionProperty.} 

UNION 

{?attr rdf:type 
qb:MeasureProperty.} 

UNION 

{?attr rdf:type 
qb:CodedProperty.} 

i 



J 

?x qb:attribute ?attr. } 

0new 

FILTER NOT EXISTS { 

{?attr rdf:type 

qb:DimensionProperty.} 

UNION 

{?attr rdf : type 
qb : MeasureProperty. } 

UNION 

{ ?attr rdf : type 
qb : CodedProperty. } 

\ 



; 

?x qb:attribute ?attr. } 




Change 

Add_Generic_Value_to_Observation( o,p,v) 

Delete_Generic_Value_}'rom_Observation{ o, p, v) 

Intuition 

Add a generic value to observation 

Delete a generic value from an observation 

Parameters 

0 = 'I'he observation 

0 = The observation 


p = The property related as predicate of the obser¬ 

p = The property related as predicate of the obser¬ 


vation 

vation 


V = The added value 

V = The deleted value 

SPARQL used 

SELECT ?o ?p ?v WHERE { 

SELECT ?o ?p ?v WHERE { 

for detection 

GRAPH <v2> { 

GRAPH <vl> { 


FILTER NOT EXISTS { 

FILTER NOT EXISTS { 


{?p rdfrtype qb:DimensionProperty.} 

{?p rdf:type qb:DimensionProperty.} 


UNION 

UNION 


{?p rdfrtype qb:MeasureProperty.} 

} 

{?p rdf:type qb:MeasureProperty.} 

} 


} 

GRAPH <v2> { 

} 

GRAPH <vl> { 


?o qbrdataSet ?ds . 

?o qb:dataSet ?ds. 


?ds qb:structure ?ft. 

?ds qb:structure ?ft. 


?ft qb:component ?cs. 

?ft qb:component ?cs. 


?cs qb:componentProperty ?p. 

?cs qb:componentProperty ?p. 


?p rdfs:range ?v. 

?p rdfs:range ?v. 

i 


/ 

FILTER NOT EXISTS { GRAPH <vl> { 

J 

FILTER NOT EXISTS { GRAPH <v2> { 


?o qb:dataSet ?ds. 

?o qb:dataSet ?ds . 


?ds qb:structure ?ft. 

?ds qb:structure ?ft. 


?ft qb:component ?cs. 

?ft qb:component ?cs. 


?cs qb : componentProperty ?p. 

?cs qb : componentProperty ?p. 


?p rdfs:range ?v. 

} 

} 

} 

?p rdfs:range ?v. 

} 

} 

} 

5+ 

(o,qb : dataSetyds), {ds,qb : structure, ft), 
(ft, qb : component, cs), (cs, qb : 

componentProperty,p), (p, rdfs : range,?;) 

0 

s- 

0 

(o,qb : dataSetyds), {ds,qb : structure, ft), 
(ft,qb : component, cs), (cs,qb : 

componentProperty,p), (p, rdfs : range,?;) 

4^old 


FILTER NOT EXISTS { 

{ ?p rdf:type qb : DimensionProperty. } 
UNION 

{ ?p rdf:type qb : MeasureProperty. } 

} 

^new 

FILTER NOT EXISTS { 

{ ?p rdf:type qb : DimensionProperty. } 
UNION 

{ ?p rdf:type qb : MeasureProperty. } 

} 





